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.
I’ve been involved in database technologies for 20 years now. During that time, I have read numerous prognostications from various industry pundits proclaiming that the next release of so-and-so database would be so simple to administer that the product would no longer require DBAs for support. Replace “database” with any technology, and you’ll find that the same industry mantra occurs.
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!
SQL Server 2012 introduced a feature called project parameters. Of course, like many other developers, I was stuck on not fixing something that was not broken. Over time, I learned that project parameters are very beneficial features to use, especially when moving a package from DEV to QA and finally to PROD. Let’s take a quick look at how to set up package parameters and how to use them to manipulate connection strings at runtime.
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.
For most, walking into the office and grabbing that first cup of coffee signals the start to the workday. But for the team of remote DBAs at RDX, their job never truly stops. They’ll attest that it comes with the territory; that providing 24x7 database administration services requires them to always be in tune with the environments they manage. When you’re responsible for critical data stores, the typical 9am-5pm doesn’t quite cut it.
One, out of many, criteria we use to evaluate candidates for positions at RDX (Remote DBA Experts) is their communication skills. Because we are a remote services provider, our ability to have “face-to-face” communications with our customers is somewhat limited. Most of the communications that occur are through e-mails, ticket comments and conference calls.