Home Dashboard Directory Help
Search

Database startup occurs under user SPID when SQL Server service starts by James Lupolt


Status: 

Closed
 as By Design Help for as By Design


1
2
Sign in
to vote
Type: Bug
ID: 790242
Opened: 6/15/2013 5:33:03 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

Upon restarting SQL Server, we found that one database started under a user SPID. The following messages appeared in the error log:

2013-06-04 14:33:41.43 spid26s     Starting up database 'FooDB1'.
2013-06-04 14:33:41.43 spid25s     Starting up database 'FooDB2'.
2013-06-04 14:33:41.43 spid28s     Starting up database 'FooDB3'.
2013-06-04 14:33:41.43 spid23s     Starting up database 'FooDB4'.
2013-06-04 14:33:41.43 spid11s     Starting up database 'FooDB5'.
2013-06-04 14:33:41.43 spid30s     Starting up database 'FooDB6'.
2013-06-04 14:33:41.43 spid59     Starting up database 'FooDB7'.
2013-06-04 14:33:41.43 spid22s     Starting up database 'FooDB8'.
2013-06-04 14:33:41.43 spid31s     Starting up database 'FooDB9'.

Note that the 's' is missing from the SPID for FooDB7. I understand that system SPIDs can be greater than 50 since SQL 2005, but that 's' should be appended for a system SPID.

I understand also that a user SPID will be logged as starting the database if a user runs 'ALTER MyDB SET ONLINE', but wouldn't think that is a possibility here because it is occurring at service startup.

I confirmed that auto_close is not enabled on any databases. No stored procedures are marked to run at startup.

SP1 for SQL Server 2012 is installed.

Could someone comment on whether this could be a bug related to database startup? Does the code that generates those log entries just do something simple like "if spid > 50, append 's'"?

What prompted this inquiry is some unusual blocking that occurred during database startup for this database, but it's clear to me whether the blocking is related to the unusual startup log entries.
Details
Sign in to post a comment.
Posted by Microsoft on 7/26/2013 at 6:41 PM
Hello,
Thank you for submitting this feedback. The behavior you reported is expected as SQL Server allows user connections to start unstarted DBs on demand.

Thanks again for reporting the product issue and continued support in improving our product.


Thanks,
Ajay.
Sign in to post a workaround.