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.
Have you ever built a dimension in SSAS and received a blue informational warning advising you to:
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.
Recently, I had reports from one of my clients that many of their users were experiencing slowness. While investigating, I found the root cause to be a key lookup on a single function execution, completely unrelated to the activities being performed by the users. A key lookup can be a costly operation that requires additional I/O and ultimately negatively impacts performance. As we all know, the disk subsystem is the slowest part of our environments, so eliminating key lookups when you can and decreasing the amount of I/O will have a positive impact on performance.
Did you ever have one of those déjà vu moments when you are working in SQL Server and you swore you already addressed an issue? This has happened to all of us, and working in SQL Server every day, I’ve certainly had my fair share of SQL déjà vu.
As a database administrator, I have encountered many occurrences in which a business user has asked to provide the number of rows for tables within a database. If you haven’t been asked yet, I’m sure the time will come. When it does, I have a script that you can add to your toolbox that will allow you to fulfill the request!
A frequent issue that I’ve encountered while performing an installation of a SQL Server failover cluster is “The cluster resource ‘SQL Server (MSSQLSERVER)’ could not be brought online due to an error bringing the dependency resource ‘SQL Network Name (SQL2012CLS)’ online.” Upon checking the cluster events in the Failover Cluster Manager, you will find the below error.
As technology improves and organizations such as Microsoft, Oracle and IBM innovate new ways to take advantage of the cloud and big data, businesses are repeatedly told that they need to move into the future and adopt these solutions. Everywhere executives turn news sources and vendors are advertising big data and similar technologies. With the amount of press they receive, one is likely to assume that companies are retiring their relational databases in favor of their nonrelational counterparts.
One of the most critical initiatives for any organization involves building a business intelligence infrastructure and solution. Before embarking on this endeavor, it is key to put the proper resources in place for a successful business intelligence implementation and evolution.