August 28, 2012 at 2:18 pm
Definitely don't have those entries on my server.
Is it possible the server didn't do a clean shutdown? Like sudden loss of power or anything like that? It might behave differently in that case. I don't have a server right now that I can pull the power cord from while it's running, to test that. I'll have to see about setting one up. Haven't done that in a few years, and it might be fun to blow up a piece of cheap hardware again.
(I once lit a server on fire, deliberately, to see how our DR plan would work. Had the fire dept there to supervise it and everything. Was fun, and the managers were duly impressed when there was only about 0.1 second of downtime and no data loss, even with a flaming server. But don't do that without clearing and coordinating with, well, everyone. Can look bad on your resume if you do it wrong. Could also be a problem if you did this on the wrong server, and burned up expensive hardware instead of something cheap and purchased specifically for DR testing.)
Edit: Never mind. Didn't read carefully enough. Gail nailed this one, as always.
- 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
August 28, 2012 at 2:20 pm
GilaMonster (8/28/2012)
eric.lyons (8/28/2012)
8/19/2012 9:51spid17sCHECKDB for database 'NSMRulestat' finished without errors on 2009-09-20 18:00:09.840 (local time).8/19/2012 9:51spid25sCHECKDB for database 'Maint' finished without errors on 2012-08-19 03:14:55.117 (local time).
8/19/2012 9:51spid36sCHECKDB for database 'VisibData' finished without errors on 2012-08-19 03:10:05.883 (local time).
Look at the highlighted dates.
Btw, some of your databases have not had a successful checkDB in 3 years, you may want to rectify that.
Old databases -- has no activity
*****
Give a man a fish, and you've given him a meal. Teach a man to fish and he'll ask to borrow your boat.:-P
August 28, 2012 at 2:24 pm
eric.lyons (8/28/2012)
And yet, on a job interview I was very surprised to learn about the HOURS passing waiting for a VLDB to come on line because of dbcc.
I'd be very surprised to learn that too, because it's not true.
Oh, it's very possible for a DB to take hours to come online. 13 hours is the worst I've seen (1TB database), but it's not because of CheckDB. It's the database recovery process (crash recovery) taking forever due to huge transaction, very fragmented log or both. Probably both.
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
August 28, 2012 at 2:25 pm
8/19/2012 9:51 spid17s CHECKDB for database 'NSMRulestat' finished without errors on 2009-09-20 18:00:09.840 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid11s CHECKDB for database 'model' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid29s CHECKDB for database 'WORKFLOW' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid31s CHECKDB for database 'Suppliers' finished without errors on 2012-04-27 08:41:05.063 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid18s CHECKDB for database 'BEDB' finished without errors on 2009-09-20 18:04:30.660 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid33s CHECKDB for database 'AlloyNav' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid34s CHECKDB for database 'HomeDepotPOS' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid21s CHECKDB for database 'XXX' finished without errors on 2009-09-20 18:05:31.600 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid38s CHECKDB for database 'DiagramDB' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid22s CHECKDB for database 'landesk' finished without errors on 2009-09-20 18:05:32.457 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid23s CHECKDB for database 'se config DB' finished without errors on 2009-09-20 18:05:51.863 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid11s CHECKDB for database 'tempdb' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid15s CHECKDB for database 'msdb' finished without errors on 2009-09-20 18:00:06.637 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid28s CHECKDB for database 'dist_xport' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid14s CHECKDB for database 'Citrix-Performance' finished without errors on 2009-09-20 18:00:11.713 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid35s CHECKDB for database 'DW_Staging' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid20s CHECKDB for database 'XXXXDW_TEST' finished without errors on 2009-09-20 18:00:06.150 (local time). This is an informational message only; no user action is required.
8/19/2012 9:51 spid30s CHECKDB for database 'OnBase' finished without errors on 2012-06-15 12:22:43.653 (local time). This is an informational message only; no user action is required.
All of these are old databases with no activity? At my last full-time employer I ran CHECKDB weekly on my production databases. Some people might say that wasn't often enough.
August 28, 2012 at 2:25 pm
eric.lyons (8/28/2012)
GilaMonster (8/28/2012)
eric.lyons (8/28/2012)
8/19/2012 9:51spid17sCHECKDB for database 'NSMRulestat' finished without errors on 2009-09-20 18:00:09.840 (local time).8/19/2012 9:51spid25sCHECKDB for database 'Maint' finished without errors on 2012-08-19 03:14:55.117 (local time).
8/19/2012 9:51spid36sCHECKDB for database 'VisibData' finished without errors on 2012-08-19 03:10:05.883 (local time).
Look at the highlighted dates.
Btw, some of your databases have not had a successful checkDB in 3 years, you may want to rectify that.
Old databases -- has no activity
Doesn't mean they can't be corrupted due to an IO subsystem glitch. It you absolutely don't care about them at all, fine. If you use them at all, they should still get consistency checks every now and again.
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
November 7, 2013 at 8:38 am
Hi,
I had the same issue, all my error log was with the message:
starting up databases xxx checkdb for database xxx finished without errors
Below forum has helped me:
Just set the database options of Auto_Close to false.
Cheers...!!
November 8, 2013 at 2:40 pm
GilaMonster (8/28/2012)
eric.lyons (8/28/2012)
Old databases -- has no activity
Doesn't mean they can't be corrupted due to an IO subsystem glitch. It you absolutely don't care about them at all, fine. If you use them at all, they should still get consistency checks every now and again.
I'd have to agree, and say that I would either schedule regular CHECKDB runs, or drop the databases entirely. If the data doesn't matter, then drop it. If you can't drop it, then it does matter, and you should run CHECKDB regularly to spot errors.
And yes, I've seen one system where a hard drive had failed silently, and no errors appeared. Then another drive failed catastrophically, and all the errors came to light (RAID5) as actually corrupt data.
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply