As database administrators, we are always looking for ways to automate our daily processes. SQL Server Agent has always been a great tool for doing this, whether it be for scheduling regular maintenance or administrative jobs. For those of you making the leap to the PaaS offering of Azure SQL databases, you will quickly discover that SQL Server Agent is no longer a feature. For those of you who might start to panic thinking you will now be required to wake up at 2:00 AM to manually run your weekly maintenance or nightly administrative job- don’t worry! This is where Azure Automation comes to save the day! Azure Automation brings a PowerShell workflow execution service to the Azure platform that allows one to automate those maintenance and administrative tasks all within the Azure portal and take the role of the SQL Server Agent. To demonstrate how you can leverage Azure Automation, I will take a common request that I have encountered with many clients who have the need to schedule a stored procedure execution.
I recently was tasked with a project to consolidate several SQL 2005 database servers down to one existing SQL 2012 database cluster. While working on this project, I found that one of the database servers needing to be consolidated was utilizing SQL Server Reporting Services (SSRS), but the existing cluster was not configured for Reporting Services. SSRS is not cluster aware, so adding this feature to an existing clustered instance is not straightforward and will likely lead to a rule check failure on the “Existing clustered or cluster-prepared instance” rule. Well today is your lucky day, as I’m going to show you exactly how to get beyond this error and on your way to making your SSRS cluster aware!
In the world of big data, we are always trying to lighten our storage footprint. Luckily for us, Microsoft has introduced data compression as an enterprise-level feature to aid in conserving storage. Not only are you able to save on storage, you will also dramatically reduce the number of I/O requests. Knowing that the disk subsystem is the slowest part of our environments, these fewer I/O requests needed for retrieving data will lead to an increase in performance.
As technology advances and organizations grow, cloud computing and hosting are becoming a part of our organizations more and more. One of the new offerings by Microsoft is their Azure platform with one of the services being the Azure SQL database. While working with the Microsoft Azure platform during a recent project, I discovered the ability to name your own Azure SQL server in the Azure Preview Portal, a feature that isn’t available in the Azure Management Portal. I’d like to share this feature with you.
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.
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.