Beginning SQL DBA - Tips? re: Top ten error messages

[345A]

Hello,

I am a new SQL DBA and I was curious what are the 10 top ten error messages or
issues I should be aware of.

Thank you for your support.

345A (New kid on the block).

 

[Dimandja]

Here are a few.

1. Acquiring enough hardware (disks especially). As soon as any hardware is installed, some applications will find ways to saturate it.

2. Finding room for data. There is no end to partitioning data files.

3. Trying to convince application programmers that their data access routines can be greatly improved.

4. Trying to convince application programmers that you are really not responsible for the poor design of the database.

5. Attend endless meetings to determine whether the problem is item 1, 2, 3, 4 or 5 (this one), instead of rewriting the applications.

Dimandja

 

[griffindm]

I take exception to some of these remarks.

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"

http://www.decisionsupportgroup.com

 

[SQLSister]

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.

 

[Dimandja]

Hi all,

I AM a developer! My post was written tongue-in-cheek. The same issues I illustrated can be reversed and point the finger at DBAs.

Dimandja

 

[Dimandja]

Please disregard my previous post, above. It was intended for another thread - not this one.

Dimandja

 

[345A]

Thank you all for your replies. I appreciate your support.