Not to start a flame war here, but I was in a major argument with a new DBA over a stored procedure designed to populate a datamart with a lot of disparate de-normalized summary data. The process took up to six hours to run on MS SQL Server 6.5 and would hang about one time in twenty. After the upgrade to MS SQL Server 7 the same code ran in fifteen minutes and ran without a hang from that point on (over a year now).
Let's not pile on the blame on the developer.
Regards,
Dave Griffin The Decision Support Group
Reporting Consulting with Cognos BI Tools
"Magic with Data"
Dave has a point, ultimately seeing the developer as the enemy will work to your disadvantage as a dba. The point is to work together to make the product as good as possible.
Some thing you may run into as a beginner:
Huge growth of the transaction log - caused by failure to backup the transaction log periodically.
Inability to restore database in the event of a crash - casued by failure to setup and run backups on a periodic basis or failure to understand how the restore process works. Also failure to perform transaction backups frequently enough - management may say they can afford to lose a days worth of transactions until they actually do!
Slow running queries due to lack of indexing.
Problems managing permissions because you set them for each individual rather than using roles.
Jobs or DTS packages which run fine when you manually execute them, but which do not when you schedule them. Mostly due to SQL Server agent permissions vice your own personal permissions.
Difficulty figuring out what to move from development server to production server after version 1 is released. I use a third party product to check the differences and help script the changes.
Everyone in your organization having the sa password and hard coding it in web applications. Or worse, having no sa password, so anyone at all can hack into your databases. Rule one - set an sa password. Rule two, only give it to dbas, rule three - don't let anyone use a system admin login as the hard coded connection from a web page.
People making unauthorized changes to Production databases. Do not give developers rights to make changes on a production database, all changes should be made in a development database and then moved by a dba only after testing. Do not let people break your production database in the name of a quick fix.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.