October 20, 2010 at 11:22 am
Steve Jones - SSC Editor (10/19/2010)
I think there's a little elitist mentality, but someone ought to know how to do this in scripting. It's much more efficient, especially when you start getting lots of logs to restore. Or you want automation.
AND...
Oliiii (10/20/2010)
Every DBA wannabe can use the GUI to restore a DB, sadly, way less can write down the 5 words and 1 path script for a simple restore, the whole point of the test is to see what you can do and your objective is to show it to me.
Really? Okay, what you and I consider senior may differ here, but just because a dba wannabe using the GUI matches what most seniors do simply because it's the easiest tool without having to do 10 minutes of syntax lookup for something you rarely do. If your environment actually has the room to do nightly restore tests, you're lucky. I can barely get space half the time in most places simply to get my dev environment expanded, nevermind a sandbox for daily production restores just to 'test'.
What's something a DBA *would* do daily that you might script? Review for deadlock/blocks... check. Crack open perfmon and take a look at the baseline. Check. Restore a database to a point in time... um... no.
Besides, the GUI has this nice thing of 'restore to xyz time'. It finds my logs (as long as I haven't been pushing them all over the server), and does it for me. Why in heck's name am I reinventing the wheel unless I *have* to? Sure, daily scriptings require scripts. One off restores require a rt-click, data data data, run. Move on with life.
This is a silly conversation to even have for me. If I had this in an interview I'd be more scared that they were reading interview questions online then having any clue what the average day to day responsibilities usually are. Even setting this up to automate would be a one-off thing. Crack BOL, get the syntax, modify as necessary, possibly create a little automated file detection via SSIS to feed into the syntax, and off you go, done. See you in 4 years for the next version.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
October 21, 2010 at 3:13 am
GSquared (10/20/2010)
Why?Maybe I'm the exception, but I don't spend a significant portion of my time running restore scripts on a day-to-day basis, hence I haven't bothered to even begin to memorize the syntax. I can read it out of BOL and type from scratch, but what I'm more likely to do if I need it, is open up the wizard, build the basic restore I need, click the "Script This" button, and then modify the resulting script, while confirming my modifications in BOL.
If you read my previous post you would see that it's exactly what i'm looking for 🙂
Craig Farrell (10/20/2010)
Really? Okay, what you and I consider senior may differ here, but just because a dba wannabe using the GUI matches what most seniors do simply because it's the easiest tool without having to do 10 minutes of syntax lookup for something you rarely do.
Of course you can't find out if someone is a "senior" DBA with just one question, it's just one of the many questions i'll ask.
My role in the interview is to find out if you have what we are looking for, your role is to show me what you know.
I don't really care about the restore command, the only thing i care is how you do it.
And if while you are doing it you tell me about other stuffs like maintenance plan, backup validation and DRP, i'll be even happier.
Here is the answer to my restore question:
RESTORE DATABASE MyDB FROM DISK = 'cut and paste path'
First of all, if you need a 10 mins (heck even a 2 mins) lookup in BOL to do that then there is a serious problem here, while noone expect any kind of senior DBA to know the command by heart, i do expect them to find something so obvious in no time.
I expect 4 kind of answer to the question:
You type it out like that because you happen to know the syntax by heart: All good for me, but i'll have to ask you another question to find out how you look for things you don't know.
You either type some of it and uses BOL to check your syntax or you use BOL from the start: All good for me, you showed me you are not affraid to type t-sql and i could see how you search for answers in BOL (this can be good or bad, depending on how you do it).
You use the wizzard to generate the script: All good, you showed me you know you can script stuff and you would rather spend 5sec reviewing the script before blindly running it (everyone can miss click an option in a wizzard).
You use the wizzard to do the restore: I'm not happy because i don't know how you type some simple t-sql, i don't know if you are just taking the easy way or if you are not worried about mistake you could have made and i don't know how you search for things in BOL (or have a wizzard generate it for you). I'll have to ask you another question to make you search for something in BOL and a question to make you type some t-sql. You've just lost 5 mins in your interview while you could have used the extra time to tell me something else.
This is the reason i don't like people using only the wizzard -in an interview-, in the end i don't know much more about you.
There is another reason but it's specific to the kind of job we do here (which is not related to being a "senior" DBA).
Here each DBA has to manage between 1000 and 3000 DBs, you are expected to do prety much anything from monitoring to optimising to auditing to suporting users and providers. With that kind of load you are strongly encouraged to script and automate anything you do, and anyone who worked in that kind of environment will be a script maniac and will script even the smallest thing.
If i see someone using a script to restore the DB i'm happy because i might have found another maniac that might get ready to work alone in less time that someone else.
Once i'm done with the restore question, i keep asking many other questions, each depending on the kind of answer i get.
Giving an answer i wouldn't find good doesn't mean you'll go home right away, i'll just ask you something else, the only problem is i don't have all day for your interview so i might not have the time to ask all i want or find out all i want, which is always bad for you.
October 21, 2010 at 1:29 pm
A) No, what I described doesn't match what you're asking. If you ask me to restore a database from a backup file, I'll use the wizard for it. I won't even bother with the scripting step. Why would I? I said I'd script it out from the wizard, IF I need something more complex than what the wizard can generate for me.
B) I know DBAs who are one step above being script kiddies who can do what you just described as a "senior DBA test". They can open BOL, look up "restore", and type up the command for a simple restore. These are people who are FAR from being "senior" DBAs.
That's the part I don't get about what you're asserting. Yeah, you need to test basic technical technique, but this test doesn't filter senior vs junior, it filters "is a DBA of one sort or another" vs "hasn't a single clue". I'm not saying it's not a valid part of an interview. I'm saying it's not a valid test of senior vs junior.
- 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
October 22, 2010 at 2:48 am
I understand your point of view, i admit my view of what is a "senior" DBA is influenced by my work, where some mistake/inefficiencies are not allowed (something you cannot guarantee by relying only on the wizard). But that might be only a requirement here (or in this kind of company only).
I would like to point out that the restore test is just one of many questions, it's kinda useless on it's own, it's just there to steer the interview.
October 22, 2010 at 6:22 am
Oliiii (10/22/2010)
I understand your point of view, i admit my view of what is a "senior" DBA is influenced by my work, where some mistake/inefficiencies are not allowed (something you cannot guarantee by relying only on the wizard). But that might be only a requirement here (or in this kind of company only).I would like to point out that the restore test is just one of many questions, it's kinda useless on it's own, it's just there to steer the interview.
You can't depend on scripting 100% either.
Nothing mankind engages in is error-free.
The best approach, in my experience, is expect mistakes to be made, and have enough resources and expertise to be able to recover from them. Minimize them, yes. Mitigate them, yes. Prevent as many as is cost-effective, yes. But try by some artificial means like using scripts instead of a GUI to avoid them entirely? Won't work.
- 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
October 22, 2010 at 9:35 am
GSquared (10/22/2010)
You can't depend on scripting 100% either.Nothing mankind engages in is error-free.
But with a script you can test it and retest it so when it has to work you can be fairly confident that it will work. An ad-hoc process is not nearly as reliable and those that depend on ad-hoc processes and, usually, not nearly as reliable and certainly not repeatable.
October 22, 2010 at 9:48 am
If I'm restoring a database for the first time, or one that I don't do regularly enough to already have a script for, I will always go through the GUI, generate the script, and then execute the t-sql manually.
First off..it's just plain faster, especially when you don't know the exact filenames for the database, or have a bunch of files that need to go to different places (not just a replace).
Second..if for any reason the process locks up while you're doing it through the GUI, ALL of SSMS will lock up, and you'll have to force-close it. If you run the script manually, you can just open a new window and kill your session...there is no chance of your entire SSMS locking up and losing other scripts you may have open/unsaved.
I will use the GUI to generate the script for things because it's just plain faster, but because of the way SSMS handles it, I will never execute it from there unless there is no other option.
October 22, 2010 at 9:56 am
I am curious why no one has stated the obvious, if you are a Senior DBA you have a script that will take any database name and file path and figure out where it wants to go, validate if the backup is there and validate if a database currently exists and restore the database including any move statements if necessary. It should be a tool you already have in your DBA tool box, you never need to reinvent something (unless the database vendor changes the nature of their backup and recovery). If you are or have been a lone DBA then it is essential you have these time saving tools and make your work load flow a little easier. In an interview they may not want you loading your personal scripts onto their network or server, but they may preview your code and unless they have a Senior DBA looking over it odds are they have no idea what your script is doing.
October 25, 2010 at 1:41 pm
Derrick Smith (10/22/2010)
If I'm restoring a database for the first time, or one that I don't do regularly enough to already have a script for, I will always go through the GUI, generate the script, and then execute the t-sql manually.First off..it's just plain faster, especially when you don't know the exact filenames for the database, or have a bunch of files that need to go to different places (not just a replace).
Second..if for any reason the process locks up while you're doing it through the GUI, ALL of SSMS will lock up, and you'll have to force-close it. If you run the script manually, you can just open a new window and kill your session...there is no chance of your entire SSMS locking up and losing other scripts you may have open/unsaved.
I will use the GUI to generate the script for things because it's just plain faster, but because of the way SSMS handles it, I will never execute it from there unless there is no other option.
The restore/backup GUI opens in a separate window with a separate process. It doesn't lock up the rest of SSMS.
The advantage of having a script you can save for reference/reuse is valid.
- 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
October 26, 2010 at 8:47 am
i've noticed that a lot of DBA's tend to specialize and rarely change ways of doing things. i've seen DBA's who can write very complicated code but don't know a lot of the operational things. and vice versa. and i've seen SQL dev's who write SQL 2000 code with all kinds of carp that shouldn't be there even though we have been running SQL 2005 for years. and they refuse to write the new code.
and then of course everyone has different opinions about everything in SQL. just look at the thread about the surrogate keys article. lately i've been creating a lot of clustered indexes on date columns and other columns that aren't int or very unique in the table. the reason is that the way the queries are structured this gives us the best performance. it's not exactly what the book says, but in our case it works. a few years ago i had the idea to change the clustered index on a 200 million row table to a not very unique row and it solved a huge performance issue that was costing a lot of money
and everyone does things differently. i use netbackup for SQL backups and rarely use the SQL code or GUI for backups and restores. one time i had an exchange admin interview years ago and didn't know a lot of things because i was used to doing things one way and not the way the company did it.
October 27, 2010 at 11:16 am
I've been a DBA for 9 years and I've never held the title Senior DBA anywhere I've worked although my pay and responsibilities are those of a DBA that is senior level. Personally for me, the title of Senior doesn't mean anything. I would have no problem applying and interviewing for any company looking for a senior level DBA. Experience is always situational and no DBA will know everything, but the important thing is to be able to determine their broad basic level of experience and then narrow down the knowledge, experience and expertise they bring to the position you are hiring for. A person administering a few VLDB's in a 24/7 production environment for three years is going to bring to the table a whole different skillset than someone who has been administering multiple databases, but who's primary responsibilty is data architecture and reporting in an localized environment.
October 27, 2010 at 3:37 pm
I'd have to say, with all due respect to the various posters before me, that being a Senior DBA is not a matter of whether you use the GUI or the Command Line to restore the database, but whether you have the attitudes and practices of a Senior DBA.
I have been a DBA on two separate systems using completely different technologies, and the semantics of the language which I use to do the task are largely irrelevant.
What is relevant is a solid grasp of the role of a DBA. A Senior DBA (by my standards) is one who can articulate and enact the roles and responsibilities appropriately. For example, someone who understands that a backup is worthless unless it can be restored successfully has the attitudes I would expect of a Senior DBA. Someone who believes that when everything is running smoothly, that only means that you haven't identified the problem has nearly enough professional paranoia to be a Senior DBA.
Let's stop focussing on the Script vs GUI wars (both are entirely appropriate) and focus on the real question.
By what yardstick should we measure a Senior DBA? Is Professional Paranoia is a requirement!
Edit: Apparently my speelung isn't prefect!
October 27, 2010 at 5:52 pm
SQL Server is a vast product. And there more than a few types of DBA's (Operations, Development, BI, Data Mining, Performance Tuning specialists, Reporting specialists, SSIS specialists, SQL coding specialists, etc.). I seriously doubt that any of us will live long enough to have used the entire product; and, it keeps changing.
I've never been to a DBA interview where I could answer every interviewer's pet questions. And, conversely, they could never answer all of mine.
Every DBA has unique experience.
What should be most important to an interviewing company is finding a DBA candidate with enough knowledge to be effective in the particular environment for which he/she is applying for a job, a high aptitude for DBA work, and interest in learning more about use of the product to satisfy the company's requirements.
LC
October 28, 2010 at 2:19 pm
Toby Harman (10/27/2010)
I'd have to say, with all due respect to the various posters before me, that being a Senior DBA is not a matter of whether you use the GUI or the Command Line to restore the database, but whether you have the attitudes and practices of a Senior DBA.I have been a DBA on two separate systems using completely different technologies, and the semantics of the language which I use to do the task are largely irrelevant.
What is relevant is a solid grasp of the role of a DBA. A Senior DBA (by my standards) is one who can articulate and enact the roles and responsibilities appropriately. For example, someone who understands that a backup is worthless unless it can be restored successfully has the attitudes I would expect of a Senior DBA. Someone who believes that when everything is running smoothly, that only means that you haven't identified the problem has nearly enough professional paranoia to be a Senior DBA.
Let's stop focussing on the Script vs GUI wars (both are entirely appropriate) and focus on the real question.
By what yardstick should we measure a Senior DBA? Is Professional Paranoia is a requirement!
Edit: Apparently my speelung isn't prefect!
Same way I defined a "senior DBA" earlier in this thread: A senior DBA knows WHY to do things a particular way, and can explain the options and pros and cons for each.
Instead of worrying about how to get a particular backup/recovery task done, the senior DBA knows why backups are done particular ways, knows what options to choose for a particular scenario, and knows that no backup plan is worth anything at all unless it's part of a broader recovery plan. A senior DBA can come up with a valid recovery plan, worked out based on real business needs and resources, and either implement it or delegate that to a technician/junior DBA.
And so on, through the field of specialization that he has as a senior DBA.
It's not about what tools a person uses. It's not about HOW, it's about WHY.
Anyone can learn to restore database backups, through a variety of tools, and be good at it. But if they don't know WHY a database would ever be recovered to "read only", or whatever, but only HOW to do so, they aren't senior. That's my criterion.
Breadth of knowledge counts, of course, but it has to be around why more than how, in my opinion.
- 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
October 29, 2010 at 1:46 am
I have found that DBAs that have worked alone for a while generally think that they are quite advanced, because in reality, they have had no-one to mentor them; and no-one to compare themselves with.
To compound the problem, recruitment agencies will rate your level of experience based on the number of years that you have been a DBA, especially if you have all the right buzz words in your CV. Some CVs we've received even have a little matrix at the top stating technology, number of years working with said technology and their experience level.
Phil
While all answers are replies, not all replies are answers.
Phil
Although all answers are replies, not all replies are answers.
Blog: http://philjax.wordpress.com
Viewing 15 posts - 31 through 45 (of 187 total)
You must be logged in to reply to this topic. Login to reply