Question about detaching databases.

I need to have someone clarify a couple things for me.
1. If a system running MSDE is rebooted in the middle of a transaction, I
am assuming at some point when the system is restarted, the transaction log
file is rolled back into the main database file. However, if a database is
detached before anyone connects to it, will the uncommitted transaction log
data be rolled into the main database file before the detach is performed?
2. When exactly does the uncommitted transaction log data get rolled back
into the database after a reboot in the middle of a transaction?
--
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
hi Ken,
Ken Varn wrote:
> I need to have someone clarify a couple things for me.
> 1. If a system running MSDE is rebooted in the middle of a
> transaction, I am assuming at some point when the system is
> restarted, the transaction log file is rolled back into the main
> database file. However, if a database is detached before anyone
> connects to it, will the uncommitted transaction log data be rolled
> into the main database file before the detach is performed?
when a system stops (crashes or is unproperly shut down), all the pending
transactions are aborted ..
when the SQL Service restarts, it will stars and recover all databases...
that's to say committed transaction will be rolled forward and uncommitted
rolled back.. the algorithm is quiet complex as SQL Server searches the best
method to perform this task to put the db on line and available as soon as
possible..
so you are not entitled to detach the db before the db has been recovered..
you can perhaps move the physical files before starting SQL Server, but then
the db will be marked as corrupted as SQL Server can no longer find the db
files as registered in it's system tables, so this is not a good idea...
> 2. When exactly does the uncommitted transaction log data get rolled
> back into the database after a reboot in the middle of a transaction?
as soon as the db is recovered... if you open the log file of SQL Server, in
the \Log folder, and inspect one of the ERRORLOG files you'll see something
like
2005-08-11 16:33:22.45 spid8 Starting up database 'msdb'.
2005-08-11 16:33:22.48 spid9 Starting up database 'pubs'.
2005-08-11 16:33:22.49 spid10 Starting up database 'Northwind'.
2005-08-11 16:33:22.51 spid11 Starting up database 'a'.
2005-08-11 16:33:23.17 spid5 Clearing tempdb database.
2005-08-11 16:33:23.21 spid11 Starting up database 'atest'.
2005-08-11 16:33:24.35 spid5 Starting up database 'tempdb'.
2005-08-11 16:33:24.45 spid3 Recovery complete.
....
if something is pending fo a specific database you'll see rollforwad and
rollback operations...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||> so you are not entitled to detach the db before the db has been
recovered..
> you can perhaps move the physical files before starting SQL Server, but
then
> the db will be marked as corrupted as SQL Server can no longer find the db
> files as registered in it's system tables, so this is not a good idea...
So that I can clarify what you are saying here. SQL Server will not allow
you to detach a database until it has completed the recovery process?
I basically want to know if it is safe to get rid of the LDF file after a
database has been detached without any adverse ramifications, like database
corruption.
--
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:3m3sgtF159l9rU1@.individual.net...
> hi Ken,
> Ken Varn wrote:
> when a system stops (crashes or is unproperly shut down), all the pending
> transactions are aborted ..
> when the SQL Service restarts, it will stars and recover all databases...
> that's to say committed transaction will be rolled forward and uncommitted
> rolled back.. the algorithm is quiet complex as SQL Server searches the
best
> method to perform this task to put the db on line and available as soon as
> possible..
> so you are not entitled to detach the db before the db has been
recovered..
> you can perhaps move the physical files before starting SQL Server, but
then
> the db will be marked as corrupted as SQL Server can no longer find the db
> files as registered in it's system tables, so this is not a good idea...
> as soon as the db is recovered... if you open the log file of SQL Server,
in
> the \Log folder, and inspect one of the ERRORLOG files you'll see
something
> like
> 2005-08-11 16:33:22.45 spid8 Starting up database 'msdb'.
> 2005-08-11 16:33:22.48 spid9 Starting up database 'pubs'.
> 2005-08-11 16:33:22.49 spid10 Starting up database 'Northwind'.
> 2005-08-11 16:33:22.51 spid11 Starting up database 'a'.
> 2005-08-11 16:33:23.17 spid5 Clearing tempdb database.
> 2005-08-11 16:33:23.21 spid11 Starting up database 'atest'.
> 2005-08-11 16:33:24.35 spid5 Starting up database 'tempdb'.
> 2005-08-11 16:33:24.45 spid3 Recovery complete.
> ...
> if something is pending fo a specific database you'll see rollforwad and
> rollback operations...
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
|||hi Ken,
Ken Varn wrote:
> So that I can clarify what you are saying here. SQL Server will not
> allow you to detach a database until it has completed the recovery
> process?
until the recovery has been completed, SQL Server does not allow to touch
all dbs at all... it is still "starting"...

> I basically want to know if it is safe to get rid of the LDF file
> after a database has been detached without any adverse ramifications,
> like database corruption.
actually you should not get rid of the LDF file at all, as it is a needed
part of a database... even when the simple recovery model is used you should
always provide all transaction log files... you can use
sp_attach_single_file_db when they are not present but best practice implies
forwarding them too...
say you have a db file named [myDb] with 1 physical data file as
C:\..\myDb.Mdf and a t-log file C:\..\myDb.Ldf...
you only provide me the C:\..\myDb.Mdf instructing me to attach it via
sp_attach_single_file_db ...
on my system I already have another company sw which uses a db with the very
same physical data files (and names)...
the corresponding datafile will be C:\..\myDb.Mdf as the log file in
C:\..\myDb.Ldf
as I can not put your db in the same folder I move it to
C:\anotherDir\myDb.Mdf and use sp_attach_single_file_db ... the problem,
now... SQL Server try to create a new t-log file using the available info
(sysfiles and sysfiles1 system table) and will point to the other company
database C:\..\myDb.Ldf physical file...
that log file will be pointed by 2 db and will immediately raises exception
marking 1 of the 2 db as suspect...
to solve this problem I need the t-log of your db and the use of
sp_attach_db indicating all the required physical files..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||> actually you should not get rid of the LDF file at all, as it is a needed
> part of a database... even when the simple recovery model is used you
should
> always provide all transaction log files... you can use
> sp_attach_single_file_db when they are not present but best practice
implies
> forwarding them too...
> say you have a db file named [myDb] with 1 physical data file as
> C:\..\myDb.Mdf and a t-log file C:\..\myDb.Ldf...
> you only provide me the C:\..\myDb.Mdf instructing me to attach it via
> sp_attach_single_file_db ...
> on my system I already have another company sw which uses a db with the
very
> same physical data files (and names)...
> the corresponding datafile will be C:\..\myDb.Mdf as the log file in
> C:\..\myDb.Ldf
It sounds as if as long as I do not try to attach a database onto a system
that has the same database name I can use sp_attach_single_file_db with no
adverse affects. Or, are there other issues that I should be concerned
with?
Basically, without trying to go into too much detail here, our system has an
automated process that periodically detaches databases, removes the ldf file
and archives the mdf file. The system may re-attach any of these databases
again at a later time depending on certain circumstances. We have been
seeing some database corruption issues and have tried to determine if this
process is the cause. We do know that occasionally the system is restarted
due to power failures (although the UPS is doing an orderly shutdown) and we
want to figure out if our detach and removal of LDF file process could be
the cause of databases getting corrupt after we re-attach them during a
restart from a power fail.
--
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:3m444tF155s4gU1@.individual.net...
> hi Ken,
> Ken Varn wrote:
> until the recovery has been completed, SQL Server does not allow to touch
> all dbs at all... it is still "starting"...
>
> actually you should not get rid of the LDF file at all, as it is a needed
> part of a database... even when the simple recovery model is used you
should
> always provide all transaction log files... you can use
> sp_attach_single_file_db when they are not present but best practice
implies
> forwarding them too...
> say you have a db file named [myDb] with 1 physical data file as
> C:\..\myDb.Mdf and a t-log file C:\..\myDb.Ldf...
> you only provide me the C:\..\myDb.Mdf instructing me to attach it via
> sp_attach_single_file_db ...
> on my system I already have another company sw which uses a db with the
very
> same physical data files (and names)...
> the corresponding datafile will be C:\..\myDb.Mdf as the log file in
> C:\..\myDb.Ldf
> as I can not put your db in the same folder I move it to
> C:\anotherDir\myDb.Mdf and use sp_attach_single_file_db ... the problem,
> now... SQL Server try to create a new t-log file using the available info
> (sysfiles and sysfiles1 system table) and will point to the other company
> database C:\..\myDb.Ldf physical file...
> that log file will be pointed by 2 db and will immediately raises
exception
> marking 1 of the 2 db as suspect...
> to solve this problem I need the t-log of your db and the use of
> sp_attach_db indicating all the required physical files..
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>
|||hi Ken,
> It sounds as if as long as I do not try to attach a database onto a
> system that has the same database name I can use
> sp_attach_single_file_db with no adverse affects. Or, are there
> other issues that I should be concerned with?
should not... SQL Server will try to recreate the log file(s) based on the
original info... and if no "problem" is found it should be able to correctly
attach the db..

> Basically, without trying to go into too much detail here, our system
> has an automated process that periodically detaches databases,
> removes the ldf file and archives the mdf file. The system may
> re-attach any of these databases again at a later time depending on
> certain circumstances. We have been seeing some database corruption
> issues and have tried to determine if this process is the cause. We
> do know that occasionally the system is restarted due to power
> failures (although the UPS is doing an orderly shutdown) and we want
> to figure out if our detach and removal of LDF file process could be
> the cause of databases getting corrupt after we re-attach them during
> a restart from a power fail.
missing log files in recovery moment can be a problem... I'd archive the log
files as well, even in simple recovery model..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.15.0 - DbaMgr ver 0.60.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply