As RDX gears up for an exciting 2016 full of user groups, trade shows, and regional events, there are a handful of upcoming SQL Saturdays at which you can find experts from RDX. SQL Saturdays are free, one-day training events and are held in cities worldwide throughout the year. SQL Server professionals of all levels are encouraged to attend as speaking sessions range from beginner to advanced. There are also a variety of networking opportunities available such as pre-conference sessions in select cities and after parties.
As business intelligence continues to make a big splash into businesses, SSAS and cubes are becoming a requirement. One of the limitations that DBAs face every day is converting from reading and writing T-SQL statements to being able to read and write MDX with ease. In order help others who may have been thrown into the role, I am going to start a series on MDX code writing. This blog post will be geared towards translating a simple T-SQL SELECT statement into an MDX SELECT statement.
I have found that database snapshots are under-utilized and wanted to show an example of how efficient it is to use them prior to a code deploy for the purpose of recovering a single table or reverting an entire database from a snapshot in the event of unexpected functionality within an application.
From database configuration to performance and maintenance, DBAs are responsible for the most critical data essential to business functionality and success. The knowledge they hold regarding database security, availability, recoverability, performance, and numerous other areas makes them critical to the success of the company. Also tasked with designing database data stores, a DBA’s expertise allows them to consult on company solutions aimed at reducing operation costs, improving margins, and more – simply put, they allow organizations to make better business decisions.
The database engine has played an increasingly strategic role in virtually all organizations for over two decades. Over the years, the database’s area of influence has expanded to a point to where it has become the heart of the modern IT infrastructure.
If you cannot install SQL Server 2008 because of the known issue in the Setup program, you will have to use the slipstream method to successfully complete an installation of SQL Server. This method involves downloading the service pack package that you want for your architecture and combining that with the original SQL Server 2008 install media.
Recently, I was tasked with building a hierarchy using multiple dimensions. I was advised to use a named query or materialized view to accomplish this because SSAS doesn’t have the capabilities to read the columns/attributes from multiple dimensions. Since I have done this before, I decided to take the AdventureWorks database and give a step-by-step tutorial of how to accomplish this request. Let’s get started!
During your life as a DBA, you will probably have to restore the master database and all the user databases on a new operating system to bring an already existing SQL Server instance online. One of my clients recently had an issue with hardware failure. Our only option was to install SQL Server on a new OS and use the backup files to restore all the databases from the old SQL Server instance. Once the new system was completely built and we restored msdb, we noticed that some of the SQL Server Agent jobs began to fail. Below is the error output from the job history. It states that the CMDEXEC subsystem failed to load.
It’s late, you’re tired, and all you want is your head to hit the pillow – all DBAs know the feeling. It was a long day to begin with, and just as you drifted off to sleep, your cell phone rings. All of a sudden you need to log back into your datacenter and troubleshoot a critical database that became unresponsive. End users need access to this data before they sit down at their desk in the morning – so sleep isn’t an option.
Ever look at a screen’s output and get that puckered feeling in the pit of your stomach? If you have been working in this profession for any amount of time, you know the feeling I’m talking about. The feeling that makes you think you would rather be living in Montana making woodcarvings at a roadside stand than being a DBA. I’ll be taking a somewhat lighthearted look at the perils of our profession and discuss ways to reduce problem occurrences.
Have you ever built a dimension in SSAS and received a blue informational warning advising you to:
Any business can attest to how important their data is to the functions of their company; without it, everything comes to a halt. But what is sometimes overlooked are the individuals tasked with administering that data and its surrounding environments. In the worst of cases, a business experiences a catastrophic event, like a corrupted server, and slips into panic-mode as no one at the company knows how to correct the issue – or, the sole individual in charge of your databases can’t be reached. Businesses know they can’t afford to have this happen, but:
In effort to clean up database environments, we as DBAs are often asked to either move tables to a different file group or to consolidate multiple filegroups and the number of database files into one. The recommended way of accomplishing this task is to drop and create a clustered index on the new filegroup; however, whenever the clustered index is also a primary key, this process becomes very inefficient and resource-intensive since we have to drop all of the foreign keys, the clustered primary key, and then recreate the clustered primary key and all of its dependencies.