IT professionals operate in a complex and constantly evolving work environment that demands a high degree of precision and attention to detail. Department procedures and best practices are typically codified and supply the foundation from which employees obtain guidance on how to properly perform their jobs. This information base and quality training should enable your human resources such as DBAs to navigate the complexities of their responsibilities while keeping mistakes to a minimum.
No one is perfect, and despite the best training and intentions, occasionally mistakes are made. In many cases, a blunder can cause serious repercussions to the IT environment and its users. Usually, corrective measures can be taken to minimize the damage and the individual responsible for the gaffe learns a hard lesson which makes it unlikely that they will repeat it.
There are, however, instances where the error is so egregious that it cannot be glossed over even with the most persuasive arguments. Some of the mistakes that a DBA might make have such negative impacts on the business’s finances or reputation that it cannot be ignored and demands punitive action to be taken against the offender. Here are some pitfalls for DBAs to avoid if they would rather be optimizing code than polishing up their CV.
Errors That Can Lead to the Unemployment Line
While many of the mistakes that you might make as a DBA result in some degradation in database performance or availability, others can result in severe repercussions to the business that relies on these systems. Here are some of the most serious errors that you can make as an SQL Server DBA. It’s in your best interest to avoid making them.
Not having viable backups – Maintaining backups to facilitate system restoration in the event of an outage or disaster is perhaps the most important task that a DBA performs regularly. If a critical business database crashes and cannot be restored due to the lack of a good backup it could cripple an organization. There will be no tolerance for excuses as to why the backup is not available. If you were responsible for ensuring that the database was backed up and failed to verify that the procedure was running correctly, you might soon be looking for a new database to administer. Testing your backup and restore procedures is a critical step in protecting your databases and your income.
Disabling page verification – SQL Server has built-in facilities to guard against data corruption. Page verification can be set to the value of checksum, torn page detection or none. None is never a default and this setting should not be set by a competent DBA. Enabling the none setting leaves you open to undetected database corruption. When corruption is finally discovered through other means and the post-mortem indicates that a DBA turned off page verification, chances are good that the DBA will soon be relocating.
Undetected database corruption – Database corruption can occur for many reasons that are out of the control of a DBA. Detecting corruption before it causes serious consequences is a practice that a thorough DBA should engage in regularly. Periodically running integrity checks using DBCC CHECK command should be part of a DBA’s regimen of preventative actions. Undetected corruption will affect backups and lead to the inability to restore a database even if backups have been taken.
Security oversights – Security is of great concern across the IT environment, and SQL Servers are no exception. There are several mistakes that a DBA can make regarding security that will result in a quick exit from their current place of employment. One is to provide elevated permissions to unauthorized individuals. In addition to enabling this individual to access information that should be restricted, the presence of elevated permission in the wrong hands can cause your organization to fail a compliance audit.
Sharing passwords – It is a basic fact understood by all IT professionals that passwords should not be shared. Sharing a password negates audit controls and can obscure the true culprit if steps are taken that impact the integrity of a database. There is never a compelling justification for a DBA to share a password that enables access to an SQL Server instance. If you are guilty of this transgression, you might be looking for a new place to practice your craft.
It’s not too late for a DBA to institute procedures to alleviate these concerns. These items should be at the top of your list when developing a schedule of your administrative tasks.
The Right Tool Can Simplify a DBA’s Life
SQL Diagnostic Manager for SQL Server by IDERA simplifies the complexities of managing and monitoring SQL Server instances no matter where they are hosted. While it does not directly address the issues described above that can cost a DBA their job, the tool simplifies the tasks of monitoring and managing their databases. This provides them with more time to ensure they never fall victim to the major mistakes that could lead to termination by their current employer.
With SQL Diagnostic Manager for SQL Server, you can monitor all of your SQL instances whether they are on-premises or in the cloud from a single tool. It provides expert recommendations that can assist with performance optimization. Create effective alerts with settings to avoid the problem of false alarms. You can even obtain a summary of the most pressing issues and alerts affecting your databases.
Using SQL Diagnostic Manager for SQL Server will enable your database team to spend the proper amount of time to avoid the critical errors which can lead to business and personal disaster. Help your DBAs keep their jobs. They need them!