March 13, 2007 at 5:21 am
Hi,
I've got a MSDE installation, and I have one problem. The service starts
correctly, but, I don't know why, the databases don't startup correctly. If
you take a look at the server log, you'll see that between two startups of
databases can pass about 40 minutes!!! Does anybody know why that happens??
The autoclose option is OFF, I only get the startup message once.
Date Source Message
2007-03-13 10:15:18.01 server Logging SQL Server messages in file
'C:\Archivos de programa\Microsoft SQL Serv
2007-03-13 10:15:18.01 server Server Process ID is 592.
2007-03-13 10:15:18.01 server All rights reserved.
2007-03-13 10:15:18.01 server Copyright (C) 1988-2002 Microsoft
Corporation.
2007-03-13 10:15:18.01 server Microsoft SQL Server 2000 - 8.00.2039 (Intel
X86) ...
2007-03-13 10:15:18.04 server SQL Server is starting at priority class
'normal'(2 CPUs detected).
2007-03-13 10:15:18.40 server Working Set size set to 778944 kilobytes.
2007-03-13 10:15:18.40 server Using dynamic lock allocation. [500] Lock
Blocks, [1000] Lock Owner Blocks.
2007-03-13 10:15:18.40 server SQL Server configured for thread mode
processing.
2007-03-13 10:15:18.42 spid2 Starting up database 'master'.
2007-03-13 10:15:18.92 spid5 Starting up database 'model'.
2007-03-13 10:15:18.92 server Using 'SSNETLIB.DLL' version '8.0.2039'.
2007-03-13 10:15:18.95 spid2 Skipping startup of clean database id 8
2007-03-13 10:15:18.95 spid2 Skipping startup of clean database id 7
2007-03-13 10:15:18.95 spid2 Skipping startup of clean database id 6
2007-03-13 10:15:18.95 spid2 Skipping startup of clean database id 5
2007-03-13 10:15:18.95 spid2 Skipping startup of clean database id 4
2007-03-13 10:15:18.95 spid2 Server name is 'PC\IPS'.
2007-03-13 10:15:18.98 server SQL server listening on 127.0.0.1: 1433.
2007-03-13 10:15:18.98 server SQL server listening on 192.168.1.10: 1433.
2007-03-13 10:15:18.99 server SQL server listening on TCP, Shared Memory,
Named Pipes.
2007-03-13 10:15:19.01 server SQL Server is ready for client connections
2007-03-13 10:15:19.39 spid5 Clearing tempdb database.
2007-03-13 10:15:20.21 spid5 Starting up database 'tempdb'.
2007-03-13 10:15:20.39 spid2 SQL global counter collection task is created.
2007-03-13 10:15:20.39 spid2 Recuperación completa.
2007-03-13 10:15:39.29 spid51 Starting up database 'DB1'. ----- HERE!!
2007-03-13 10:17:16.35 spid51 Starting up database 'DB2'. ----- HERE!! 2
minutes...
2007-03-13 10:56:38.48 spid55 Utilizando 'xpstar.dll' versión
'2000.80.2039' para ejecutar el procedimiento a
2007-03-13 10:56:38.76 spid55 Starting up database 'msdb'. ----------- 40
minutes!!!
2007-03-13 10:58:18.21 spid55 Starting up database 'DB3'.
2007-03-13 10:58:18.28 spid55 Starting up database 'DB4'.
Thanks!!
Arnau.
March 13, 2007 at 7:08 am
Very strange. HAve you run DBCCs on them? Any issues accessing them once they are open?
If you try to access one before it's started, does it work?
March 13, 2007 at 7:55 am
I'm seeing that the user databases are skipped and then TEMPDB comes up. I don't believe user databases can be restored prior to ALL the system databases being restored. Why is it trying to do them out of order? I don't know. Do you have this on a cluster? SAN drive? Where is the TEMPDB located compared to the other system databases and the user databases?
-SQLBill
March 13, 2007 at 10:54 am
Looks like I tried to open the database too early, because I've changed my service to retry the connection to the database a few seconds later and looks like it's going fine.
My service has a dependency with SQLServer so it shouldn't start before SQLServer does, but maybe it's not enough.
Thanks!!
March 13, 2007 at 2:00 pm
It's not about the service...it's about the databases. TEMPDB MUST be restored first. If you clicked on the databases or tried to connect before the TEMPDB came up....it will try to bring up the user databases and fail.
-SQLBill
March 14, 2007 at 4:47 am
It's a normal computer, a intel dual core, with local ide drives and no clustering. There's nothing strange, I think.
If I try to connect to the database too early, it raises an error that it cannot connect to the database specified in the login.
I understand, for what you say, that until the TEMPDB has been restored, I cannot connect to any user database, am I wrong?
Thanks!
March 14, 2007 at 1:59 pm
That is correct...until TEMPDB is available you can't do anything.
-SQLBill
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply