Where do I start?!
-
Hello,
I am working for a company that is just getting off the ground. It was started by a few guys that new how to sell a product. It is doing well I might add.
However, none of the guys are DBAs. This is one of the reasons they have hire me.
The problem(s):
1) They have a ton of stuff for me to automate, schedule and create.
2) There is no test environment. Everything is being done in one database (the production database).
3) They see a need, change something and go to the next thing.
4) Nothing is documented.
5) No backup plans at all. (I guess they are relying on server backups).
6) There are at full speed ahead for this next project, this next client and so on.
I'm looking at this and saying what a minute. I don't even know your database and your wanting me to change the DTS packages!
Has anyone been thrown into a environment where they are the first DBA for company?
1) How do you slow the boss down to document the environment, plan backups and develop a test environment when he hired you for all the "NEW" stuff for the new clients?
2) What are some of the first things you that are more experienced would do if you were in my situation as the first DBA of a growing fledgling company that is going at round the clock speed?
I am curious what some of the senior DBAs would tell me to do first.
Thanks.
Tony
Things will work out. Get back up, change some parameters and recode.
-
WebTechie38 (3/14/2009)
How do you slow the boss down to document the environment, plan backups and develop a test environment when he hired you for all the "NEW" stuff for the new clients?That would be the key... he didn't hire you for all the old stuff. He hired you for the new stuff. And, as you said, they're not DBA's themselves. Explain the risks of not doing the things you said. Let the Boss decide what risks to take or not and do your best to protect the boss where you think too much risk is being taken.
What's worse than going in as the first DBA is going in after a bad DBA. I realized that I couldn't fix everything over night. So, I told the boss about the mess, that I could only peel one potatoe at a time, and that I was going to start with the critical low hanging fruit to protect the data. "They" agreed.
It's a tough balancing act between what you know is right and what "the boss" wants and you do have to do both. I feel for ya. Hang in there.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
I've been in a similar (though not quite as messy) situation as the one you described.
If I was in your situation then I would be very keen to set up Database backups. It's not too big a job and can save you lots of trouble. Depending on your situation and the business needs you may only have to set up one maintenance plan that backs up every database each night.
The second thing on my list would be a dev environment. Depending on the type of application you are using this could be as simple as setting up a local copy of the database on your own machine. Restore it each morning from the previous backup.
Hopefully these two tasks would not be too time consuming and take you off other duties....
Moving forward it will be worthwhile finding your own way to track all changes and document them appropriately. Maybe that means a change request document for each change... Maybe it means one spreadsheet with a long list of changes.
These are just the things I would personally do first.
Bevan
-
Backups are the first thing. Absolutely. Straighten them out first. The damage done by any mistakes that they make (or that you make) can ultimately be limited by the quality of your backups.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font] -
"..Explain the risks of not doing the things you said. Let the Boss decide what risks to take or not and do your best to protect the boss where you think too much risk is being taken..."
Exactly, and explain that a few hours of time and some cheap space for backup storage can be the difference between a thriving business and closing up shop. If something happens and they don't want to pay for backups, you don't want to be the one taking the blame.
-
Hey, I think I worked there.
Bevan had the advice I followed and it worked well. Make a backup and then whack a table a developer needs if you have to to make the point backups are important.
After you get the dev environment, start enforcing some security in production. Unless you have rock star developers, and possibly even then, you will have people creating instability by making changes in production. Slow that down slightly.
As you make changes, however, make sure that you are also getting other work done and driving things forward while you backfill.
-
I worked somewhere similar, everyone in the company had 'sa' privs on production. Made for a few entertaining late night phone calls followed by some serious screaming matches the next day.
If they hired you to get the databases in hand, then verify with the boss that you can, in fact, do your job. As several others have said, start with backups. First and most important. Also get space, statisitcs and index maintenance routines in place. That's the easy part. You have to get them off the production server. Once you get them off, as Steve said, you have to start shutting down security. After that, you can start working on performance monitoring, teaching the dev's tsql best practices, influencing database design, etc.,
Good luck. In my case, I lasted nine months at the company before I walked out. They failed shortly afterwards (not related to me, but certainly related to their methods and practices).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
I would hope that you were hired because they recognized a need for better database management, so I'd start by putting together a list of issues that you believe need to be addressed and why and present it to the boss.
This is AFTER getting a backup plan in place. You can point your boss to this blog post[/url] about the JournalSpace.com debacle to justify backups.
Then I'd work on getting a dev environment up.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question -
Jack Corbett (3/16/2009)
I would hope that you were hired because they recognized a need for better database management, so I'd start by putting together a list of issues that you believe need to be addressed and why and present it to the boss.This is AFTER getting a backup plan in place. You can point your boss to this blog post[/url] about the JournalSpace.com debacle to justify backups.
Then I'd work on getting a dev environment up.
Wow! I haven't read that before. Hard to believe that in this day & age, in a technology company, that they didn't take into account something as fundamental as backups. However, based on the posts coming through every day, it's pretty clear that this is far from a rare circumstance.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
I am working for a company that is just getting off the ground...1) How do you slow the boss down to document the environment, plan backups and develop a test environment when he hired you for all the "NEW" stuff for the new clients?
2) What are some of the first things you that are more experienced would do if you were in my situation as the first DBA of a growing fledgling company that is going at round the clock speed?
I am curious what some of the senior DBAs would tell me to do first.
Tony
First the disclaimer: I'm not a DBA but have been a developer in this situation at a very small company.
The two keys here are "small company" and what they don't know.
The above posts are good advice especially backups - I'll come back to backups.
#2 - start by doing what they need.
They hired you to be useful, and they won't understand that you're being useful if you tell them how much analysis it will take to change a DTS package that one of the developers could do in much less time.
Explain the difference between a db backup and a server backup; how the second is good but not a replacement of the first.
Get an agreement from your boss that you should be spending a certain amount of time (2hrs, whatever) analyzing and rewriting the existing stuff. Start with an analysis, show the boss and the developers that query "X" takes much more processing time because an index wasn't used, or because they used a cursor when it wasn't necessary, or whatever.
This analysis/teaching will help you gain their trust - which you will need later when you make the case that the developers should no longer have sa access to production 😀
Start building your case that they need a new production database. Put a plan in place to migrate the production 'stuff' to this new db and have the developers switch to the new one. You will never pry them out of the current db - you don't have the social capital required for that much leverage, so get a new box and make that production.
If you don't quit, this advice should last you three months 🙂
Remember to pick your battles!
HTH,
-Chris C.
P.S.
#1 - Drop the whole "documentation" idea for at least six months.
Until you control that production server your docs won't be worth spit 15 days after you write them. Having the correct level of documentation is an art and you don't want to start with too much - ease them into it.
-
Setting up DB back up should not be a big problem. So start there.
What you will need to do is to get their trust and to show that you are worth the time and money they are spending on you.
Check if they have Dead Lock Flag set up in start up parameters. If they dont have set it up and keep an eye on it. If you catch one dead lock and then show the Bosses the dead lock, and give them a remedy for the dead lock, they will be quite happy. (There are lots of developers and DBAs who do not know how to catch a dead lock)
Check for performance of stored proc. Tune couple of stored procs and let the bosses know.
While doing all these things, make sure you also do what they want you to do. That is the DTS.
Once you have the trust, you can start making things more efficient like having a better approach to security, Testing and all the other things.
-Roy
-
JournalSpace.com wasn't the most recent failure through lack of backups.
http://www.brentozar.com/archive/2009/03/backup-fail-magnolia-goes-under/
-
Yes, I have been the first DBA for two different companies.
I recommend getting backups and whatever other maintenance you need, automated first. If that means working a weekend, since you don't have time during all the other stuff going on, so be it.
Second, create what they want. Do it efficiently and well, and get any backlog caught up as rapidly as possible.
Third, move that kind of thing over to a dev environment. Test and Dev on a separate machine from production. Even if it's someone's desktop computer, that'll be a start. Dream big, start small.
Keep in mind that as you put order into a system, chaos will blow off out of it. Prepare to confront unexpected developments, simply by keeping your equilibrium as an individual.
Finally, have fun! That kind of situation looks like chaos at first, because it is, but it's generally highly creative chaos, and it can be a heck of a fun ride.
By prioritizing, being stable, and getting things under control one piece at a time, you'll eventually get it where it needs to be. Even WW II was won one bullet/bomb at a time.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
-
Thanks everyone for the feedback.
It was very helpful!!!
I made an extensive list of things that need to be worked on:
1) Backups
2) Test Environment
3) Migration process
4) Implementing a source control for versioning (they were naming the dts packages with a version number as part of the name)
5) Standards document so all developers use the same naming convention for tables, columns, indexes, etc.
I also went through the DTS packages and questioned some coding techniques.
I spoke of the need to create maintenance plans for reindexing the indexes and checking statistics.
In other words a very to the point bulleted list of items of my concerns.
I informed the boss that I wanted to operate on his agenda and his priority. I felt obligated to point out some things and he could dictate when I would address the issues.
The verdict:
Excellent work and very good recommendations. He was very happy with my recommendations. We talked for an hour today about priorities.
I'm off and running without being overwhelmed.
Thanks again for the advice!
Things will work out. Get back up, change some parameters and recode.
-
At the top of my list to my boss was the fact we need to have backups.
Again, he liked my recommendations and gave me the go ahead to work on some things now as well as hit some critical work that needs to get done.:D
Tony
Things will work out. Get back up, change some parameters and recode.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply