January 6, 2011 at 11:26 am
GilaMonster (1/6/2011)
Craig Farrell (1/6/2011)
Best way to start that research is get yourself a small partition on a drive (usually your C:\ is smaller), create a database, and fill it with stuff until your Transaction Log is out of room. You'll get some errors. Start researching those errors. It's a common issue.Good idea, but I'd suggest limiting the size of the log, not filling C drive up. Windows gets a little twitchy when there's no free space on C.
Spoiling all my fun, Gail. The best way to learn how to deal with a truly fragged up computer is to make one. Sadly... I've actually walked onto a site that had a server like that. That was an experience to get going again as a glorified Level I thinking I was actually good at my job. 😉
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
January 6, 2011 at 11:32 am
GilaMonster (1/6/2011)
Craig Farrell (1/6/2011)
Best way to start that research is get yourself a small partition on a drive (usually your C:\ is smaller), create a database, and fill it with stuff until your Transaction Log is out of room. You'll get some errors. Start researching those errors. It's a common issue.Good idea, but I'd suggest limiting the size of the log, not filling C drive up. Windows gets a little twitchy when there's no free space on C.
Which, to me, sounds like a good idea for disaster prep. If you've never had to deal with SQL on a server that's twitchy, you'll be tharn the first time it happens.
Just don't do it on a production server. VM or re-imagable test box is best.
- 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
January 6, 2011 at 11:44 am
GSquared (1/6/2011)
GilaMonster (1/6/2011)
Craig Farrell (1/6/2011)
Best way to start that research is get yourself a small partition on a drive (usually your C:\ is smaller), create a database, and fill it with stuff until your Transaction Log is out of room. You'll get some errors. Start researching those errors. It's a common issue.Good idea, but I'd suggest limiting the size of the log, not filling C drive up. Windows gets a little twitchy when there's no free space on C.
Which, to me, sounds like a good idea for disaster prep. If you've never had to deal with SQL on a server that's twitchy, you'll be tharn the first time it happens.
Just don't do it on a production server. VM or re-imagable test box is best.
I would certainly opt for the VM if available. Repeated testing is made easier and faster that way.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 6, 2011 at 11:49 am
I dug around with a search engine a bit, and "sev3/sev4" refers to software support "severity level". There aren't standard definitions, but it appears that the higher the number, the lower the importance/impact of the incident, with 3 and 4 being, generally, stuff that barely matters or is merely affecting performance, without affecting accuracy or stopping the show. Sev1 would be a down server, a corrupt production database, crashed internet connection, and so on, that cause alarm bells to sound and people to run around and flap their arms and make chicken noises. Sev2 is stuff that affects production but isn't stopping the show. Sev5 appears to generally be things like a background color on the UI making something a little hard to read, or a font someone doesn't like (i.e., should be fixed, but when it's appropriate/convenient).
Which makes the question kind of odd. I'd expect an interviewer to be more interested in prevention/cure of sev1/sev2 than 3/4.
Pretty obvious that, if you have proper DR in place, like automatic failover on to a standby server, a lot of sev1 can be mitigated to 2 or even 3. That would be of interest. But handling of sev3/4? Who cares? Doesn't show anything useful about an interview candidate.
Of course, I'd add to the list sev0. That's where the whole company is shut down and goes out of business because of some system/server/farm disaster. Sev-1, where whole civilizations are destroyed by IT errors (it's gotta happen someday). Sev-2, where humanity itself is threatened by an IT mistake (Terminator, et al). Not sure whether -3 would be destruction of a planet or the whole physical universe being wiped out (LHC doing something they really didn't plan for maybe? Ice Nine?). It's completely extensible!
- 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
January 6, 2011 at 12:16 pm
GSquared (1/6/2011)
I dug around with a search engine a bit, and "sev3/sev4" refers to software support "severity level". There aren't standard definitions, but it appears that the higher the number, the lower the importance/impact of the incident, with 3 and 4 being, generally, stuff that barely matters or is merely affecting performance, without affecting accuracy or stopping the show.
LOL. -10: Big Bang inverts. MS Error: An unfathomed error has resulted in the universe, and your solid state drives are now compressed with two trees and a sun. Data is corrupted. Please run DBCC CHECKDB.
You're correct in your searching: Sev1-6 (usually) are usually associated with SLAs (Service Level Agreements). Depending on the location Sev 1/2 are usually catastrophic business failures, with 2 being a vendor based item that the team has little control over.
As you mentioned, 3/4 are usually performance based issues that are affecting the company but are not affecting profit or customer relations. One example I remember offhand was our shipping tracking was down at one location. It was important, but we could still do business online. Think standard 'trouble ticket'.
These are usually encoded in SLA contracts when you've got a provider doing IT support or front end maintenance (IE: Running the online business site for a Fortune 500) and different severities have different requirements for resolution time and penalties for falling outside that resolution window. They'll also have different escalation impacts.
IE: Sev 1: 24/7 support: Call 1 DBA, 1 Developer, 1 System Adminstrator, 1 Business Analyst, immediately. At all times until closed, the conference line must be populated by a member of these groups.
For comparison:
Sev4: Leave the DBA team an email for the morning to put it in their queue.
Hmm, that rambled a bit.
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
January 6, 2011 at 9:47 pm
Craig Farrell (1/6/2011)
GilaMonster (1/6/2011)
Craig Farrell (1/6/2011)
Best way to start that research is get yourself a small partition on a drive (usually your C:\ is smaller), create a database, and fill it with stuff until your Transaction Log is out of room. You'll get some errors. Start researching those errors. It's a common issue.Good idea, but I'd suggest limiting the size of the log, not filling C drive up. Windows gets a little twitchy when there's no free space on C.
Spoiling all my fun, Gail. The best way to learn how to deal with a truly fragged up computer is to make one. Sadly... I've actually walked onto a site that had a server like that. That was an experience to get going again as a glorified Level I thinking I was actually good at my job. 😉
Thank you very much for making me understand craig 🙂
____________________________________________________________________
Going in one more round when you don't think you can - that's what makes all the difference in your life --Rocky Balboa
Believe you can and you're halfway there. --Theodore Roosevelt
January 7, 2011 at 12:45 am
GSquared (1/6/2011)
I dug around with a search engine a bit, and "sev3/sev4" refers to software support "severity level". There aren't standard definitions, but it appears that the higher the number, the lower the importance/impact of the incident, with 3 and 4 being, generally, stuff that barely matters or is merely affecting performance, without affecting accuracy or stopping the show. Sev1 would be a down server, a corrupt production database, crashed internet connection, and so on, that cause alarm bells to sound and people to run around and flap their arms and make chicken noises. Sev2 is stuff that affects production but isn't stopping the show. Sev5 appears to generally be things like a background color on the UI making something a little hard to read, or a font someone doesn't like (i.e., should be fixed, but when it's appropriate/convenient).
Thing is, there's no standard definitions so there's nothing stopping a particular company (like maybe the one the OP interviewed at) defining the severity levels on an ascending scale, so eg of a sev 4 would be meteor hit server room, eg of a sev 3 would be production DB down.
It's the kind of thing that if asked in an interview has to be immediately followed up by 'what do you defines as a sev4 incident?'
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 7, 2011 at 6:23 am
GilaMonster (1/7/2011)
GSquared (1/6/2011)
I dug around with a search engine a bit, and "sev3/sev4" refers to software support "severity level". There aren't standard definitions, but it appears that the higher the number, the lower the importance/impact of the incident, with 3 and 4 being, generally, stuff that barely matters or is merely affecting performance, without affecting accuracy or stopping the show. Sev1 would be a down server, a corrupt production database, crashed internet connection, and so on, that cause alarm bells to sound and people to run around and flap their arms and make chicken noises. Sev2 is stuff that affects production but isn't stopping the show. Sev5 appears to generally be things like a background color on the UI making something a little hard to read, or a font someone doesn't like (i.e., should be fixed, but when it's appropriate/convenient).Thing is, there's no standard definitions so there's nothing stopping a particular company (like maybe the one the OP interviewed at) defining the severity levels on an ascending scale, so eg of a sev 4 would be meteor hit server room, eg of a sev 3 would be production DB down.
It's the kind of thing that if asked in an interview has to be immediately followed up by 'what do you defines as a sev4 incident?'
Yep.
- 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
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply