Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Downtime Expand / Collapse
Author
Message
Posted Thursday, February 19, 2009 11:51 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 3:31 PM
Points: 33,051, Visits: 15,159
Comments posted to this topic are about the item Downtime






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #661067
Posted Friday, February 20, 2009 10:33 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 3:31 PM
Points: 33,051, Visits: 15,159
A broken URL has no answers today

However here's one I got in email:

For the record, the main reason to remove SPs that are surplus to requirements is to ensure that nobody uses them. Imagine an old and unmaintained stored procedure is used by someone and it has a bug or causes a performance issue... think of the amount of time and effort that would be required in troubleshooting and correcting the mess this might cause!

Far better to force a user to specifier their requirements or think through their own stored procedure, I think.

Code maintenance and software development is hard, and extraneous and unmanaged code is awful. I should know, I work for a vendor (EMC Infra) and code that our clients customize that isn't being used or is badly spec'ed is often the code that causes us the most amount of problems









Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #661505
Posted Friday, February 20, 2009 11:14 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, July 10, 2014 4:29 PM
Points: 1,082, Visits: 538
Whew! I thought I was going crazy or the network was! Thank goodness it was just you and these crazy links!

Downtime: No. Didn't have any last year. Had a power outage but the back-ups and generators all worked. A few people lost/locked their terminal sessions because they didn't plug into the proper side of the UPS strip, but no data loss or downtime.

Pruning: Not a regular exercise. Once a year, or so. And I let things linger for 2 1/2 years, not just 6 months. I find when I get assigned a 'new' project, I'm usually rehashing through an older project that I did, or someone here did, about 2 years ago.
Post #661546
Posted Friday, February 20, 2009 11:49 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
The company I currently work for had a heat-related massive downtime issue a month or so before I started here. From what I understand, the AC failed, and alerts that should have gone out, didn't.

I caused some downtime once by making a mistake with the default login used by a linked server, but that's not the kind of downtime you're asking about here.

I think most of the downtime I've seen has been because of poorly set up and maintained hardware. But that was years ago with a sysop who really shouldn't have been in that business. Downtime was hours per month at that place.

The best "the whole network is down" I've been through was when a salesperson ended up with Slammer on a copy of SQL Express he had on his laptop, and plugged that into the LAN and brought the whole place to its knees. He wasn't even sure why he had SQL on the laptop, much less how he got Slammer in there. Took all morning for the admin to figure out what was going on.


- 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
Post #661586
Posted Friday, February 20, 2009 2:21 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 1:11 PM
Points: 2,508, Visits: 3,695
We have very little downtime.

Pruning is something that occurs once a year. On our system i, I can use a command to tell the last time an object was used. I've written queries to tell me if the last usage was more than two years. We can then analyze it to determine if anybody really needs it.

I'm still pretty new to SQL Server and haven't looked into how this would be done. It would be handy to do it though.
Post #661774
Posted Monday, February 23, 2009 1:13 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Friday, July 18, 2014 8:06 AM
Points: 558, Visits: 1,154
Purging of stored procedures is usually because there are so many it is difficult to see the wood for the trees! If they could be divided into sub-directories in the same way as integration services packages can in msdb then life would be a lot easier.
Post #662402
Posted Monday, February 23, 2009 2:08 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:27 AM
Points: 7,001, Visits: 8,438
knock on wood

the unplanned downtimes we had were:
- during fire detection system tests, the backup power unit was shut down because of a little shot circuit by one of the electricians.
All non-critical servers were still working

- SAN servers lost SAN connection during online activation of SAN-switch duplexing, which shoudn't be a problem according the the SAN manufacturer.

- One of the non-sysadmins thought he should reboot a server, wasn't able to do it using RDB, so he entered the server room and pulled the power cables ... out of the wrong server.

- extreme temperature exposure caused some servers to stop working.
(we had some very hot days last year) That server cabinet has been modified with an airco unit.

- data upgrade because of new application rollout destructed data because of some last minute changes by the dev team.
The restore operation took more than the planned downtime window.

- in one occasion a non dba added a non-sysadmin sqlaccount to the
sysadmin group of sqlserver, and applications got messages
"object does not exists.." ....
That was finally thé issue that got us the approval to restrict sysadmin membership.

- we also has a downtime caused by yours truly, because even tough
the logon trigger had been tested for some time,
not every actual situation had occurred and an instance got unresponsive.
DAC saved my but.


Yes, we did have some hard disk failures, and because of it were raid volumns, all the sysadmins had to do was replace the disk and monitor the rebuilt process. No downtime, only slow down.

Redundancy and protection are to be considered like an insurance and cannot protect you physically against what human inventiveness ;) .


Johan


Don't drive faster than your guardian angel can fly ...
but keeping both feet on the ground won't get you anywhere

- How to post Performance Problems
- How to post data/code to get the best help


- How to prevent a sore throat after hours of presenting ppt ?


"press F1 for solution", "press shift+F1 for urgent solution"


Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me
Post #662419
Posted Monday, February 23, 2009 10:16 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 3:31 PM
Points: 33,051, Visits: 15,159
If you're interested, there's a discussion on this in our LinkedIn group as well






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #662759
Posted Tuesday, February 24, 2009 10:24 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 21, 2013 2:48 PM
Points: 4, Visits: 92
I know it makes the DBA look bad, but yeah we have a lot of unplanned downtimes of production systems. Bear in mind that we have over 1600 databases on ~140 different servers and 2 DBAs, so statistically we do ok with uptime.

Number one cause. Too many people with admin rights and not enough communication. It is a cultural thing here I inherited, and I can't change. As a result we do a lot of fire fighting.

Number two cause, budget constraints. Customers want High Availability for everything, but can't pay for it. Good example here is SAN failures, I won't name specific brand, but hey they were cheap for a reason.

Other unplanned downtimes included:
- Network switch failures
- Antivirus software mis-configured killed clusters
- Autopatch turned on accidently
- AD management failures (helpdesk had power to reset service account passwords and used said power)
- Rarely, the occasional CPU, Mainboard, memory, or other physical hardware failures.






Post #663694
Posted Friday, March 13, 2009 6:09 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, July 17, 2014 2:15 PM
Points: 1,787, Visits: 594
When I came in Monday morning my main production SQL server was down due to a hardware error. After talking to tech support it was decided the box required a new motherboard. We're a small non-profit so we don't have fail-over, replication or any such thing. Fortunately I have good backups! I had just started building a replacement server so I used the new server, installed SQL, restored databases from backup and was up in two hours. Everybody was happy after that.
One thing I've learned as a DBA: backup databases, practice restoring databases. It may be boring but can save your job and your companies data!
Post #675075
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse