DBAs... is it always like this?

[KirbyWallace]

I'm getting to the point where I feel almost overwhelmed at all that I have to do. I'm both developer and DBA. And lately, I'm moving a LOT of stuff that I would normally code into an application or website, into the database itself.

For instance, I recently added a whole line of email enabled services that do not have to be told by the application to "go". The database itself, through a scheduled agent job here, or a table trigger there, is constantly querying the database, and as it detects certain conditions (a Table trigger determines that "Table A contains New Vacation Request Records", for instance, and a stored procedure is run which sends an email of the request to the supervisor of the employee identified in the request, through Notification Services (gateway to dbMail), which an Agent Job picks up and delivers to dbMail, which delivers it to Exchange, etc etc etc.)

I feel like I'm overwhlemed trying to keep track of what on the development/QA server has to be scripted and migrated to the production server. There are Agent Jobs. Triggers. SPs, Table structure changes. Views. Database Diagrams that have to be updated...

SSMS is a great IDE for SQL Server, but it still seems to depend upon me, A LOT, to keep track of all that has changed from version to version.


My question is this: Am I doing something wrong? Is there some database tool that I do not know about that can give me a list of everything that is different between one database/server and another?

Or is it more a matter of "Welcome to the DBA's world! Get used to it..."

Just looking for advice from more seasoned DBA's on this one.

 

[gmmastros]

I've never used it, but lots of people have suggested this:

http://www.red-gate.com/products/SQL_Compare/index.htm

-George

"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom

 

[DrSql]

Good reccomendation.. We also use same Red-Gate SQL Compare.
On a flip side I would suggest to off-load the work to developers by selling to your manaagemnt as deploymnet best practice is that development should provide you a set of scripts that includes roll-back as part of change management. This should provide you adequte time to test and deploy in prod.
Good luck.

Dr.Sql
Good Luck.

 

[KirbyWallace]

It seems like there's obvioulsy a lot to do in a real DBAs role. More than I thought there would be. And I've done this a lot since 1994, and it still seems to be more to learn about every day. Red-Gate seems well worth the money. Thanks for the tip!

 

[SQLBill]

Our developers create/test new objects/process on a DEV server, then they use Change Management to request we promote the object/process to their QA server (they provide scripts). Once they test them on QA, then they send the request for us to move them into production. We do not compare DEV with QA with PROD - the developers may be having trouble with an object or process and not want it moved up a level yet. So it is on them to let us know when objects/processes are ready to be promoted.

-SQLBill

The following is part of my signature block and is only intended to be informational.
Posting advice: FAQ481-4875

 

[mjldba]

It's not like this every day, just the days the end in "y" ... including Saturday & Sunday