Recently, I had reports from one of my clients that many 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.
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.
Hacking is an entirely commonplace practice these days, even though it does seem to come as a surprise when it happens. Some film portrayals of hackers show grand data centers with flashing lights and typists furiously clicking away, obtaining entrance to secure government files. However, many hackers don't need highly sophisticated software to gain access to any number of locations.
Over the course of the past year or so, there have been many incidents where government and enterprise information became accessible to hackers. There was outcry from across the country, claiming that these institutions should have done more to protect the personal information of citizens and consumers.
Here's a statistic: 21 million. What is that in reference to? That's how many people have been affected by the U.S. Office of Personnel Management data breach.