Showing posts with label backups. Show all posts
Showing posts with label backups. Show all posts

Friday, March 30, 2012

Marked "IN LOAD" messages

I do restores on a daily basis. The restores are taken from DISK backups. I
am not using backup devices.
I am noticing all these errors in the log file:
Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
When I do the restore, I am using the gui (rt click on database, select
restore).
Sometimes I need to restore over an existing DB, other times I restore to a
new database.
Any ideas? I want to make sure I am doing the restores correctly and remove
these errors
Is it possible if I do not specify "Force over existing Database" that it can
cause this error?
"Kristen" wrote:

> I do restores on a daily basis. The restores are taken from DISK backups. I
> am not using backup devices.
> I am noticing all these errors in the log file:
> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
> When I do the restore, I am using the gui (rt click on database, select
> restore).
> Sometimes I need to restore over an existing DB, other times I restore to a
> new database.
> Any ideas? I want to make sure I am doing the restores correctly and remove
> these errors
|||Try using the 'WITH RECOVERY' OPTION and issue the restore command via TSQL
and not the Gui.
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...[vbcol=seagreen]
> Is it possible if I do not specify "Force over existing Database" that it
> can
> cause this error?
> "Kristen" wrote:
|||I tried doing it in TSQL......didn't work
RESTORE DATABASE test2
FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
WITH RECOVERY,
MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
Bypassing recovery for database 'test2' because it is marked IN LOAD.
Starting up database 'test2'.
Recovery is checkpointing database 'test2' (58)
"Immy" wrote:

> Try using the 'WITH RECOVERY' OPTION and issue the restore command via TSQL
> and not the Gui.
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...
>
>
|||So - to clarify, you did a full backup of your database, then copy the
database to a new location and then restore it?
What happens if you restore the backup on the same server that the backup
was taken from?
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...[vbcol=seagreen]
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
>
> "Immy" wrote:
|||And obviously I mean in a different DB name and not over the existing one ;)
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...[vbcol=seagreen]
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
>
> "Immy" wrote:
|||"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
Why do you think these are "errors"? The sql server log file contains
messages, some of which may be errors but many of which are not. The
messages you see are standard messages that indicate a successful restore
(btw - I don't think you posted all the relevant messages since there should
be a "Database restored: Database: <dbname>, creation ..." message.
|||I want to make sure the "IN LOAD" messages that I am getting will not create
any issues in the future. Do you know of any potential problems I could face
when getting this "IN LOAD" message
"Scott Morris" wrote:

> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
> Why do you think these are "errors"? The sql server log file contains
> messages, some of which may be errors but many of which are not. The
> messages you see are standard messages that indicate a successful restore
> (btw - I don't think you posted all the relevant messages since there should
> be a "Database restored: Database: <dbname>, creation ..." message.
>
>
|||For this test, I took a backup, then restored it to a new database. When I
did that I got the error.
I am only working with 1 server so I did restore the backup on the same
server that the backup was taken from.
#2 - Most of the time, I need to restore a backup (from another DB) to an
existing database. I was using the GUI for this also. I think that may be
why I am having these messages in the log.
Can you give me an idea for the #2 scenario above what my RESTORE DATABASE
options should be?
Thanks for your help with this.
"Immy" wrote:

> So - to clarify, you did a full backup of your database, then copy the
> database to a new location and then restore it?
> What happens if you restore the backup on the same server that the backup
> was taken from?
>
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
>
>
|||No I didn't post all the messages. The database did successfully restore. I
want to understand what I am doing wrong when restoring these databases so
the messages are not written to the log. Most of the time I am taking a
backup of 1 database and restoring it to another existing DB. Using the GUI
for the restore.
Any ideas?
"Scott Morris" wrote:

> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
> Why do you think these are "errors"? The sql server log file contains
> messages, some of which may be errors but many of which are not. The
> messages you see are standard messages that indicate a successful restore
> (btw - I don't think you posted all the relevant messages since there should
> be a "Database restored: Database: <dbname>, creation ..." message.
>
>

Marked "IN LOAD" messages

I do restores on a daily basis. The restores are taken from DISK backups. I
am not using backup devices.
I am noticing all these errors in the log file:
Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
When I do the restore, I am using the gui (rt click on database, select
restore).
Sometimes I need to restore over an existing DB, other times I restore to a
new database.
Any ideas? I want to make sure I am doing the restores correctly and remove
these errorsIs it possible if I do not specify "Force over existing Database" that it can
cause this error?
"Kristen" wrote:
> I do restores on a daily basis. The restores are taken from DISK backups. I
> am not using backup devices.
> I am noticing all these errors in the log file:
> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
> When I do the restore, I am using the gui (rt click on database, select
> restore).
> Sometimes I need to restore over an existing DB, other times I restore to a
> new database.
> Any ideas? I want to make sure I am doing the restores correctly and remove
> these errors|||Try using the 'WITH RECOVERY' OPTION and issue the restore command via TSQL
and not the Gui.
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...
> Is it possible if I do not specify "Force over existing Database" that it
> can
> cause this error?
> "Kristen" wrote:
>> I do restores on a daily basis. The restores are taken from DISK
>> backups. I
>> am not using backup devices.
>> I am noticing all these errors in the log file:
>> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
>> When I do the restore, I am using the gui (rt click on database, select
>> restore).
>> Sometimes I need to restore over an existing DB, other times I restore to
>> a
>> new database.
>> Any ideas? I want to make sure I am doing the restores correctly and
>> remove
>> these errors|||I tried doing it in TSQL......didn't work
RESTORE DATABASE test2
FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
WITH RECOVERY,
MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
Bypassing recovery for database 'test2' because it is marked IN LOAD.
Starting up database 'test2'.
Recovery is checkpointing database 'test2' (58)
"Immy" wrote:
> Try using the 'WITH RECOVERY' OPTION and issue the restore command via TSQL
> and not the Gui.
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...
> > Is it possible if I do not specify "Force over existing Database" that it
> > can
> > cause this error?
> >
> > "Kristen" wrote:
> >
> >> I do restores on a daily basis. The restores are taken from DISK
> >> backups. I
> >> am not using backup devices.
> >> I am noticing all these errors in the log file:
> >> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
> >> When I do the restore, I am using the gui (rt click on database, select
> >> restore).
> >> Sometimes I need to restore over an existing DB, other times I restore to
> >> a
> >> new database.
> >> Any ideas? I want to make sure I am doing the restores correctly and
> >> remove
> >> these errors
>
>|||So - to clarify, you did a full backup of your database, then copy the
database to a new location and then restore it?
What happens if you restore the backup on the same server that the backup
was taken from?
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
>
> "Immy" wrote:
>> Try using the 'WITH RECOVERY' OPTION and issue the restore command via
>> TSQL
>> and not the Gui.
>> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
>> news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...
>> > Is it possible if I do not specify "Force over existing Database" that
>> > it
>> > can
>> > cause this error?
>> >
>> > "Kristen" wrote:
>> >
>> >> I do restores on a daily basis. The restores are taken from DISK
>> >> backups. I
>> >> am not using backup devices.
>> >> I am noticing all these errors in the log file:
>> >> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
>> >> When I do the restore, I am using the gui (rt click on database,
>> >> select
>> >> restore).
>> >> Sometimes I need to restore over an existing DB, other times I restore
>> >> to
>> >> a
>> >> new database.
>> >> Any ideas? I want to make sure I am doing the restores correctly and
>> >> remove
>> >> these errors
>>|||And obviously I mean in a different DB name and not over the existing one ;)
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
>
> "Immy" wrote:
>> Try using the 'WITH RECOVERY' OPTION and issue the restore command via
>> TSQL
>> and not the Gui.
>> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
>> news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...
>> > Is it possible if I do not specify "Force over existing Database" that
>> > it
>> > can
>> > cause this error?
>> >
>> > "Kristen" wrote:
>> >
>> >> I do restores on a daily basis. The restores are taken from DISK
>> >> backups. I
>> >> am not using backup devices.
>> >> I am noticing all these errors in the log file:
>> >> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
>> >> When I do the restore, I am using the gui (rt click on database,
>> >> select
>> >> restore).
>> >> Sometimes I need to restore over an existing DB, other times I restore
>> >> to
>> >> a
>> >> new database.
>> >> Any ideas? I want to make sure I am doing the restores correctly and
>> >> remove
>> >> these errors
>>|||"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
Why do you think these are "errors"? The sql server log file contains
messages, some of which may be errors but many of which are not. The
messages you see are standard messages that indicate a successful restore
(btw - I don't think you posted all the relevant messages since there should
be a "Database restored: Database: <dbname>, creation ..." message.|||I want to make sure the "IN LOAD" messages that I am getting will not create
any issues in the future. Do you know of any potential problems I could face
when getting this "IN LOAD" message
"Scott Morris" wrote:
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
> >I tried doing it in TSQL......didn't work
> >
> > RESTORE DATABASE test2
> > FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> > WITH RECOVERY,
> > MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> > MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> >
> > Bypassing recovery for database 'test2' because it is marked IN LOAD.
> > Starting up database 'test2'.
> > Recovery is checkpointing database 'test2' (58)
> Why do you think these are "errors"? The sql server log file contains
> messages, some of which may be errors but many of which are not. The
> messages you see are standard messages that indicate a successful restore
> (btw - I don't think you posted all the relevant messages since there should
> be a "Database restored: Database: <dbname>, creation ..." message.
>
>|||For this test, I took a backup, then restored it to a new database. When I
did that I got the error.
I am only working with 1 server so I did restore the backup on the same
server that the backup was taken from.
#2 - Most of the time, I need to restore a backup (from another DB) to an
existing database. I was using the GUI for this also. I think that may be
why I am having these messages in the log.
Can you give me an idea for the #2 scenario above what my RESTORE DATABASE
options should be?
Thanks for your help with this.
"Immy" wrote:
> So - to clarify, you did a full backup of your database, then copy the
> database to a new location and then restore it?
> What happens if you restore the backup on the same server that the backup
> was taken from?
>
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
> >I tried doing it in TSQL......didn't work
> >
> > RESTORE DATABASE test2
> > FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> > WITH RECOVERY,
> > MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> > MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> >
> > Bypassing recovery for database 'test2' because it is marked IN LOAD.
> > Starting up database 'test2'.
> > Recovery is checkpointing database 'test2' (58)
> >
> >
> > "Immy" wrote:
> >
> >> Try using the 'WITH RECOVERY' OPTION and issue the restore command via
> >> TSQL
> >> and not the Gui.
> >>
> >> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> >> news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...
> >> > Is it possible if I do not specify "Force over existing Database" that
> >> > it
> >> > can
> >> > cause this error?
> >> >
> >> > "Kristen" wrote:
> >> >
> >> >> I do restores on a daily basis. The restores are taken from DISK
> >> >> backups. I
> >> >> am not using backup devices.
> >> >> I am noticing all these errors in the log file:
> >> >> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
> >> >> When I do the restore, I am using the gui (rt click on database,
> >> >> select
> >> >> restore).
> >> >> Sometimes I need to restore over an existing DB, other times I restore
> >> >> to
> >> >> a
> >> >> new database.
> >> >> Any ideas? I want to make sure I am doing the restores correctly and
> >> >> remove
> >> >> these errors
> >>
> >>
> >>
>
>|||No I didn't post all the messages. The database did successfully restore. I
want to understand what I am doing wrong when restoring these databases so
the messages are not written to the log. Most of the time I am taking a
backup of 1 database and restoring it to another existing DB. Using the GUI
for the restore.
Any ideas?
"Scott Morris" wrote:
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
> >I tried doing it in TSQL......didn't work
> >
> > RESTORE DATABASE test2
> > FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> > WITH RECOVERY,
> > MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> > MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> >
> > Bypassing recovery for database 'test2' because it is marked IN LOAD.
> > Starting up database 'test2'.
> > Recovery is checkpointing database 'test2' (58)
> Why do you think these are "errors"? The sql server log file contains
> messages, some of which may be errors but many of which are not. The
> messages you see are standard messages that indicate a successful restore
> (btw - I don't think you posted all the relevant messages since there should
> be a "Database restored: Database: <dbname>, creation ..." message.
>
>|||If I do RESTORE DATABASE test WITH RECOVERY
it doesn't actually do a restore from a backup...it just sets the RECOVERY
option correct?
"Immy" wrote:
> Try using the 'WITH RECOVERY' OPTION and issue the restore command via TSQL
> and not the Gui.
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...
> > Is it possible if I do not specify "Force over existing Database" that it
> > can
> > cause this error?
> >
> > "Kristen" wrote:
> >
> >> I do restores on a daily basis. The restores are taken from DISK
> >> backups. I
> >> am not using backup devices.
> >> I am noticing all these errors in the log file:
> >> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
> >> When I do the restore, I am using the gui (rt click on database, select
> >> restore).
> >> Sometimes I need to restore over an existing DB, other times I restore to
> >> a
> >> new database.
> >> Any ideas? I want to make sure I am doing the restores correctly and
> >> remove
> >> these errors
>
>|||"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:D9C48AE9-91FC-4752-94CB-0428A569F826@.microsoft.com...
> No I didn't post all the messages. The database did successfully restore.
> I
> want to understand what I am doing wrong when restoring these databases so
> the messages are not written to the log. Most of the time I am taking a
> backup of 1 database and restoring it to another existing DB. Using the
> GUI
> for the restore.
> Any ideas?
There isn't anything wrong and you can't directly control these messages.
These messages are not errors. Again, not everything written to the log is
an error.

Marked "IN LOAD" messages

I do restores on a daily basis. The restores are taken from DISK backups.
I
am not using backup devices.
I am noticing all these errors in the log file:
Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
When I do the restore, I am using the gui (rt click on database, select
restore).
Sometimes I need to restore over an existing DB, other times I restore to a
new database.
Any ideas? I want to make sure I am doing the restores correctly and remove
these errorsIs it possible if I do not specify "Force over existing Database" that it ca
n
cause this error?
"Kristen" wrote:

> I do restores on a daily basis. The restores are taken from DISK backups.
I
> am not using backup devices.
> I am noticing all these errors in the log file:
> Bypassing recovery for database 'xxxxx' because it is marked IN LOAD.
> When I do the restore, I am using the gui (rt click on database, select
> restore).
> Sometimes I need to restore over an existing DB, other times I restore to
a
> new database.
> Any ideas? I want to make sure I am doing the restores correctly and remo
ve
> these errors|||Try using the 'WITH RECOVERY' OPTION and issue the restore command via TSQL
and not the Gui.
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...[vbcol=seagreen]
> Is it possible if I do not specify "Force over existing Database" that it
> can
> cause this error?
> "Kristen" wrote:
>|||I tried doing it in TSQL......didn't work
RESTORE DATABASE test2
FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
WITH RECOVERY,
MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
Bypassing recovery for database 'test2' because it is marked IN LOAD.
Starting up database 'test2'.
Recovery is checkpointing database 'test2' (58)
"Immy" wrote:

> Try using the 'WITH RECOVERY' OPTION and issue the restore command via TSQ
L
> and not the Gui.
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:9FE4EEAE-6332-4F67-BA23-6D1AA00878D3@.microsoft.com...
>
>|||So - to clarify, you did a full backup of your database, then copy the
database to a new location and then restore it?
What happens if you restore the backup on the same server that the backup
was taken from?
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...[vbcol=seagreen]
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
>
> "Immy" wrote:
>|||And obviously I mean in a different DB name and not over the existing one ;)
"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...[vbcol=seagreen]
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
>
> "Immy" wrote:
>|||"Kristen" <Kristen@.discussions.microsoft.com> wrote in message
news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
>I tried doing it in TSQL......didn't work
> RESTORE DATABASE test2
> FROM DISK = 'E:\MSSQL\Backup\LVTS_Min_03122007.bak'
> WITH RECOVERY,
> MOVE 'LVTS_Min_Data' TO 'E:\MSSQL\Backup\test2_data.mdf',
> MOVE 'LVTS_Min_Log' TO 'E:\MSSQL\Backup\test2_log.ldf'
> Bypassing recovery for database 'test2' because it is marked IN LOAD.
> Starting up database 'test2'.
> Recovery is checkpointing database 'test2' (58)
Why do you think these are "errors"? The sql server log file contains
messages, some of which may be errors but many of which are not. The
messages you see are standard messages that indicate a successful restore
(btw - I don't think you posted all the relevant messages since there should
be a "Database restored: Database: <dbname>, creation ..." message.|||I want to make sure the "IN LOAD" messages that I am getting will not create
any issues in the future. Do you know of any potential problems I could fac
e
when getting this "IN LOAD" message
"Scott Morris" wrote:

> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
> Why do you think these are "errors"? The sql server log file contains
> messages, some of which may be errors but many of which are not. The
> messages you see are standard messages that indicate a successful restore
> (btw - I don't think you posted all the relevant messages since there shou
ld
> be a "Database restored: Database: <dbname>, creation ..." message.
>
>|||For this test, I took a backup, then restored it to a new database. When I
did that I got the error.
I am only working with 1 server so I did restore the backup on the same
server that the backup was taken from.
#2 - Most of the time, I need to restore a backup (from another DB) to an
existing database. I was using the GUI for this also. I think that may be
why I am having these messages in the log.
Can you give me an idea for the #2 scenario above what my RESTORE DATABASE
options should be?
Thanks for your help with this.
"Immy" wrote:

> So - to clarify, you did a full backup of your database, then copy the
> database to a new location and then restore it?
> What happens if you restore the backup on the same server that the backup
> was taken from?
>
> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
>
>|||No I didn't post all the messages. The database did successfully restore.
I
want to understand what I am doing wrong when restoring these databases so
the messages are not written to the log. Most of the time I am taking a
backup of 1 database and restoring it to another existing DB. Using the GUI
for the restore.
Any ideas?
"Scott Morris" wrote:

> "Kristen" <Kristen@.discussions.microsoft.com> wrote in message
> news:5365DC0E-0F94-4109-A028-E775E00E8A10@.microsoft.com...
> Why do you think these are "errors"? The sql server log file contains
> messages, some of which may be errors but many of which are not. The
> messages you see are standard messages that indicate a successful restore
> (btw - I don't think you posted all the relevant messages since there shou
ld
> be a "Database restored: Database: <dbname>, creation ..." message.
>
>

Wednesday, March 28, 2012

Mapped drive database backups

How would I schedule full database backups to backup to
another disk on a mapped shared network drive?
I have tried adding a disk dump device using
sp_addumpdevice. Then running the BACKUP DATABASE command
but I get the following error message:
Cannot open backup device 'pdmsdiskdump'. Device error or
device off-line.
Thanks,
Anjelina> How would I schedule full database backups to backup to
> another disk on a mapped shared network drive?
If you set up a mapped drive H: while logged in as user A, user A is the
only person who can see an H:!
Use \\UNCPath\, unless you have set SQL Server and agent to run as a domain
account with access to the share, and you set up the mapped drive while
logged in as that user.

mapped drive and backups

I mapped a drive to a different server, which has space, then tried to use
Ent. Manager to create a backup job to the mapped drive. Only, the mapped
isn't there only the local drives but the mapped appears locally to the OS.
I forgot something yes?
Thanks
HowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/kb/555128
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote in
message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
>I mapped a drive to a different server, which has space, then tried to use
> Ent. Manager to create a backup job to the mapped drive. Only, the mapped
> isn't there only the local drives but the mapped appears locally to the
> OS.
> I forgot something yes?
> Thanks
|||Hi
EM will not see mapped drives. Use T-SQL and backup to the UNC path
\\servername\sharename\file.bak.
Make sure that the SQL Server account is a domain account and has
permissions on the share.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote in
message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
>I mapped a drive to a different server, which has space, then tried to use
> Ent. Manager to create a backup job to the mapped drive. Only, the mapped
> isn't there only the local drives but the mapped appears locally to the
> OS.
> I forgot something yes?
> Thanks
|||This actually worked.
EXEC sp_addumpdevice 'disk', 'device_name',
'\\filer_name\share_name\path\file_name.ext'
"Mike Epprecht (SQL MVP)" wrote:

> Hi
> EM will not see mapped drives. Use T-SQL and backup to the UNC path
> \\servername\sharename\file.bak.
> Make sure that the SQL Server account is a domain account and has
> permissions on the share.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote in
> message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
>
>

mapped drive and backups

I mapped a drive to a different server, which has space, then tried to use
Ent. Manager to create a backup job to the mapped drive. Only, the mapped
isn't there only the local drives but the mapped appears locally to the OS.
I forgot something yes?
ThanksHowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/kb/555128
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote in
message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
>I mapped a drive to a different server, which has space, then tried to use
> Ent. Manager to create a backup job to the mapped drive. Only, the mapped
> isn't there only the local drives but the mapped appears locally to the
> OS.
> I forgot something yes?
> Thanks|||Hi
EM will not see mapped drives. Use T-SQL and backup to the UNC path
\\servername\sharename\file.bak.
Make sure that the SQL Server account is a domain account and has
permissions on the share.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote in
message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
>I mapped a drive to a different server, which has space, then tried to use
> Ent. Manager to create a backup job to the mapped drive. Only, the mapped
> isn't there only the local drives but the mapped appears locally to the
> OS.
> I forgot something yes?
> Thanks|||This actually worked.
EXEC sp_addumpdevice 'disk', 'device_name',
'\\filer_name\share_name\path\file_name.ext'
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> EM will not see mapped drives. Use T-SQL and backup to the UNC path
> \\servername\sharename\file.bak.
> Make sure that the SQL Server account is a domain account and has
> permissions on the share.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote in
> message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
> >I mapped a drive to a different server, which has space, then tried to use
> > Ent. Manager to create a backup job to the mapped drive. Only, the mapped
> > isn't there only the local drives but the mapped appears locally to the
> > OS.
> > I forgot something yes?
> > Thanks
>
>sql

mapped drive and backups

I mapped a drive to a different server, which has space, then tried to use
Ent. Manager to create a backup job to the mapped drive. Only, the mapped
isn't there only the local drives but the mapped appears locally to the OS.
I forgot something yes?
ThanksHowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/kb/555128
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote in
message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
>I mapped a drive to a different server, which has space, then tried to use
> Ent. Manager to create a backup job to the mapped drive. Only, the mapped
> isn't there only the local drives but the mapped appears locally to the
> OS.
> I forgot something yes?
> Thanks|||Hi
EM will not see mapped drives. Use T-SQL and backup to the UNC path
\\servername\sharename\file.bak.
Make sure that the SQL Server account is a domain account and has
permissions on the share.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote in
message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
>I mapped a drive to a different server, which has space, then tried to use
> Ent. Manager to create a backup job to the mapped drive. Only, the mapped
> isn't there only the local drives but the mapped appears locally to the
> OS.
> I forgot something yes?
> Thanks|||This actually worked.
EXEC sp_addumpdevice 'disk', 'device_name',
'\\filer_name\share_name\path\file_name.ext'
"Mike Epprecht (SQL MVP)" wrote:

> Hi
> EM will not see mapped drives. Use T-SQL and backup to the UNC path
> \\servername\sharename\file.bak.
> Make sure that the SQL Server account is a domain account and has
> permissions on the share.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "BrianMultiLanguage" <BrianMultiLanguage@.discussions.microsoft.com> wrote
in
> message news:C8DDEE27-FEC9-4FA7-BEFD-03048AA5A774@.microsoft.com...
>
>

Wednesday, March 21, 2012

many problems, fixed?

Hi All-
SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
there, but corruption has been in the maintenance plan log for over a year.
I made backup of db and restored as different name on different disk array.
I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
CHECKDB with repair_rebuild option. This corrected some errors, now I am
down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors. I
have compared row count on corrupt tables before and after the data_loss
option ran and my row count is the same before and after.
What else do I need to look at to see what data was loss with the
repair_data_loss option?
After ths is correct I will be working with the owner and app vendor to get
the sql and os at least patched to current levels if not upgraded.
Thanks!
I suppose you could check the size of the database and the number of indexes
in it. It doesn't sound like you have much of a choice but to go with the
repaired database anyway.
Good luck...
Ben
"Ryan Sanders" <rsanders> wrote in message
news:108nd8uapvjvbb2@.corp.supernews.com...
> Hi All-
>
> SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
> there, but corruption has been in the maintenance plan log for over a
year.
> I made backup of db and restored as different name on different disk
array.
> I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
> next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
> CHECKDB with repair_rebuild option. This corrected some errors, now I am
> down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
> repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors.
I
> have compared row count on corrupt tables before and after the data_loss
> option ran and my row count is the same before and after.
>
> What else do I need to look at to see what data was loss with the
> repair_data_loss option?
>
> After ths is correct I will be working with the owner and app vendor to
get
> the sql and os at least patched to current levels if not upgraded.
>
> Thanks!
>
|||Can anyone provide any guidance?
Thanks!
Ryan
"Ryan Sanders" <rsanders> wrote in message news:<108nd8uapvjvbb2@.corp.supernews.com>...
> Hi All-
>
> SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
> there, but corruption has been in the maintenance plan log for over a year.
> I made backup of db and restored as different name on different disk array.
> I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
> next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
> CHECKDB with repair_rebuild option. This corrected some errors, now I am
> down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
> repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors. I
> have compared row count on corrupt tables before and after the data_loss
> option ran and my row count is the same before and after.
>
> What else do I need to look at to see what data was loss with the
> repair_data_loss option?
>
> After ths is correct I will be working with the owner and app vendor to get
> the sql and os at least patched to current levels if not upgraded.
>
> Thanks!

many problems, fixed?

Hi All-
SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
there, but corruption has been in the maintenance plan log for over a year.
I made backup of db and restored as different name on different disk array.
I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
CHECKDB with repair_rebuild option. This corrected some errors, now I am
down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors. I
have compared row count on corrupt tables before and after the data_loss
option ran and my row count is the same before and after.
What else do I need to look at to see what data was loss with the
repair_data_loss option?
After ths is correct I will be working with the owner and app vendor to get
the sql and os at least patched to current levels if not upgraded.
Thanks!I suppose you could check the size of the database and the number of indexes
in it. It doesn't sound like you have much of a choice but to go with the
repaired database anyway.
Good luck...
Ben
"Ryan Sanders" <rsanders> wrote in message
news:108nd8uapvjvbb2@.corp.supernews.com...
> Hi All-
>
> SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
> there, but corruption has been in the maintenance plan log for over a
year.
> I made backup of db and restored as different name on different disk
array.
> I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
> next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
> CHECKDB with repair_rebuild option. This corrected some errors, now I am
> down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
> repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors.
I
> have compared row count on corrupt tables before and after the data_loss
> option ran and my row count is the same before and after.
>
> What else do I need to look at to see what data was loss with the
> repair_data_loss option?
>
> After ths is correct I will be working with the owner and app vendor to
get
> the sql and os at least patched to current levels if not upgraded.
>
> Thanks!
>|||Can anyone provide any guidance?
Thanks!
Ryan
"Ryan Sanders" <rsanders> wrote in message news:<108nd8uapvjvbb2@.corp.supernews.com>...
> Hi All-
>
> SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
> there, but corruption has been in the maintenance plan log for over a year.
> I made backup of db and restored as different name on different disk array.
> I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
> next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
> CHECKDB with repair_rebuild option. This corrected some errors, now I am
> down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
> repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors. I
> have compared row count on corrupt tables before and after the data_loss
> option ran and my row count is the same before and after.
>
> What else do I need to look at to see what data was loss with the
> repair_data_loss option?
>
> After ths is correct I will be working with the owner and app vendor to get
> the sql and os at least patched to current levels if not upgraded.
>
> Thanks!

many problems, fixed?

Hi All-
SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
there, but corruption has been in the maintenance plan log for over a year.
I made backup of db and restored as different name on different disk array.
I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
CHECKDB with repair_rebuild option. This corrected some errors, now I am
down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors. I
have compared row count on corrupt tables before and after the data_loss
option ran and my row count is the same before and after.
What else do I need to look at to see what data was loss with the
repair_data_loss option?
After ths is correct I will be working with the owner and app vendor to get
the sql and os at least patched to current levels if not upgraded.
Thanks!I suppose you could check the size of the database and the number of indexes
in it. It doesn't sound like you have much of a choice but to go with the
repaired database anyway.
Good luck...
Ben
"Ryan Sanders" <rsanders> wrote in message
news:108nd8uapvjvbb2@.corp.supernews.com...
> Hi All-
>
> SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
> there, but corruption has been in the maintenance plan log for over a
year.
> I made backup of db and restored as different name on different disk
array.
> I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
> next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
> CHECKDB with repair_rebuild option. This corrected some errors, now I am
> down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
> repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors.
I
> have compared row count on corrupt tables before and after the data_loss
> option ran and my row count is the same before and after.
>
> What else do I need to look at to see what data was loss with the
> repair_data_loss option?
>
> After ths is correct I will be working with the owner and app vendor to
get
> the sql and os at least patched to current levels if not upgraded.
>
> Thanks!
>|||Can anyone provide any guidance?
Thanks!
Ryan
"Ryan Sanders" <rsanders> wrote in message news:<108nd8uapvjvbb2@.corp.supernews.com>...[vbco
l=seagreen]
> Hi All-
>
> SQL7.0 SP0 NT4. I was brought in to help fix this database, backups are
> there, but corruption has been in the maintenance plan log for over a year
.
> I made backup of db and restored as different name on different disk array
.
> I ran DBCC CHECKDB on database, it reported 17,000+ consistency errors. I
> next rebuilt indexes and ran CHECKDB again. Dropped errors to 202. Ran
> CHECKDB with repair_rebuild option. This corrected some errors, now I am
> down to 94. Since it was a copy I gave it a shot and ran CHECKDB with
> repair_allow_data_loss option. After this ran, CHECKDB reports 0 errors.
I
> have compared row count on corrupt tables before and after the data_loss
> option ran and my row count is the same before and after.
>
> What else do I need to look at to see what data was loss with the
> repair_data_loss option?
>
> After ths is correct I will be working with the owner and app vendor to ge
t
> the sql and os at least patched to current levels if not upgraded.
>
> Thanks![/vbcol]

Monday, March 12, 2012

Manual backup works, automatic scheduled doesn't

I am not able to perform automatic scheduled backups of one of our databases.
This database is called StarTeam_stardraw60_db and is located within
VSDEV\STARTEAM instance of MS SQL server.
I also tried to perform an automatic backup of another database within
VSDEV\STARTEAM instance and no luck.
However, if I try to perform an automatic scheduled backup of any database
that's located under a different instance of MS SQL Server, for example,
ProjectServer database under local instance, then everything works correctly.
I'm not clear on why one works correctly, while the other doesn't.
Thanks.
Is Agent started for that instance?
How do you define the backup? TSQL job step in an Agent job? Maintenance Plan?
What version of SQL Server?
Is there any error messages in the Agent/Maint plan output file/Report file?
Did you define an output file for the jobstep/Report file for the Maint plan?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Sarah Baker" <Sarah Baker@.discussions.microsoft.com> wrote in message
news:BDDB1DB0-C1AD-4850-BB0E-BA7C16BB229B@.microsoft.com...
>I am not able to perform automatic scheduled backups of one of our databases.
> This database is called StarTeam_stardraw60_db and is located within
> VSDEV\STARTEAM instance of MS SQL server.
> I also tried to perform an automatic backup of another database within
> VSDEV\STARTEAM instance and no luck.
> However, if I try to perform an automatic scheduled backup of any database
> that's located under a different instance of MS SQL Server, for example,
> ProjectServer database under local instance, then everything works correctly.
> I'm not clear on why one works correctly, while the other doesn't.
> Thanks.
>
|||Thank you - it was the Agent not started.
"Tibor Karaszi" wrote:

> Is Agent started for that instance?
> How do you define the backup? TSQL job step in an Agent job? Maintenance Plan?
> What version of SQL Server?
> Is there any error messages in the Agent/Maint plan output file/Report file?
> Did you define an output file for the jobstep/Report file for the Maint plan?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Sarah Baker" <Sarah Baker@.discussions.microsoft.com> wrote in message
> news:BDDB1DB0-C1AD-4850-BB0E-BA7C16BB229B@.microsoft.com...
>

Manual backup works, automatic scheduled doesn't

I am not able to perform automatic scheduled backups of one of our databases.
This database is called StarTeam_stardraw60_db and is located within
VSDEV\STARTEAM instance of MS SQL server.
I also tried to perform an automatic backup of another database within
VSDEV\STARTEAM instance and no luck.
However, if I try to perform an automatic scheduled backup of any database
that's located under a different instance of MS SQL Server, for example,
ProjectServer database under local instance, then everything works correctly.
I'm not clear on why one works correctly, while the other doesn't.
Thanks.Is Agent started for that instance?
How do you define the backup? TSQL job step in an Agent job? Maintenance Plan?
What version of SQL Server?
Is there any error messages in the Agent/Maint plan output file/Report file?
Did you define an output file for the jobstep/Report file for the Maint plan?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Sarah Baker" <Sarah Baker@.discussions.microsoft.com> wrote in message
news:BDDB1DB0-C1AD-4850-BB0E-BA7C16BB229B@.microsoft.com...
>I am not able to perform automatic scheduled backups of one of our databases.
> This database is called StarTeam_stardraw60_db and is located within
> VSDEV\STARTEAM instance of MS SQL server.
> I also tried to perform an automatic backup of another database within
> VSDEV\STARTEAM instance and no luck.
> However, if I try to perform an automatic scheduled backup of any database
> that's located under a different instance of MS SQL Server, for example,
> ProjectServer database under local instance, then everything works correctly.
> I'm not clear on why one works correctly, while the other doesn't.
> Thanks.
>|||Thank you - it was the Agent not started.
"Tibor Karaszi" wrote:
> Is Agent started for that instance?
> How do you define the backup? TSQL job step in an Agent job? Maintenance Plan?
> What version of SQL Server?
> Is there any error messages in the Agent/Maint plan output file/Report file?
> Did you define an output file for the jobstep/Report file for the Maint plan?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Sarah Baker" <Sarah Baker@.discussions.microsoft.com> wrote in message
> news:BDDB1DB0-C1AD-4850-BB0E-BA7C16BB229B@.microsoft.com...
> >I am not able to perform automatic scheduled backups of one of our databases.
> >
> > This database is called StarTeam_stardraw60_db and is located within
> > VSDEV\STARTEAM instance of MS SQL server.
> > I also tried to perform an automatic backup of another database within
> > VSDEV\STARTEAM instance and no luck.
> >
> > However, if I try to perform an automatic scheduled backup of any database
> > that's located under a different instance of MS SQL Server, for example,
> > ProjectServer database under local instance, then everything works correctly.
> >
> > I'm not clear on why one works correctly, while the other doesn't.
> >
> > Thanks.
> >
>

Manual backup works, automatic scheduled doesn't

I am not able to perform automatic scheduled backups of one of our databases
.
This database is called StarTeam_stardraw60_db and is located within
VSDEV\STARTEAM instance of MS SQL server.
I also tried to perform an automatic backup of another database within
VSDEV\STARTEAM instance and no luck.
However, if I try to perform an automatic scheduled backup of any database
that's located under a different instance of MS SQL Server, for example,
ProjectServer database under local instance, then everything works correctly
.
I'm not clear on why one works correctly, while the other doesn't.
Thanks.Is Agent started for that instance?
How do you define the backup? TSQL job step in an Agent job? Maintenance Pla
n?
What version of SQL Server?
Is there any error messages in the Agent/Maint plan output file/Report file?
Did you define an output file for the jobstep/Report file for the Maint plan
?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Sarah Baker" <Sarah Baker@.discussions.microsoft.com> wrote in message
news:BDDB1DB0-C1AD-4850-BB0E-BA7C16BB229B@.microsoft.com...
>I am not able to perform automatic scheduled backups of one of our database
s.
> This database is called StarTeam_stardraw60_db and is located within
> VSDEV\STARTEAM instance of MS SQL server.
> I also tried to perform an automatic backup of another database within
> VSDEV\STARTEAM instance and no luck.
> However, if I try to perform an automatic scheduled backup of any database
> that's located under a different instance of MS SQL Server, for example,
> ProjectServer database under local instance, then everything works correct
ly.
> I'm not clear on why one works correctly, while the other doesn't.
> Thanks.
>|||Thank you - it was the Agent not started.
"Tibor Karaszi" wrote:

> Is Agent started for that instance?
> How do you define the backup? TSQL job step in an Agent job? Maintenance P
lan?
> What version of SQL Server?
> Is there any error messages in the Agent/Maint plan output file/Report fil
e?
> Did you define an output file for the jobstep/Report file for the Maint pl
an?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Sarah Baker" <Sarah Baker@.discussions.microsoft.com> wrote in message
> news:BDDB1DB0-C1AD-4850-BB0E-BA7C16BB229B@.microsoft.com...
>

Mantanace Plan not deleting old files

I have a maintanace Plan establishe that is working excep
for on nagging item. The plan does both full backups and
transaction log backups each day. It is supposed to
delete files older than 3 days old but does not. I have
to manually go and clear the old files on a regular basis
to keep from filling up the disk. I have not seen any
error or know what to look for to see if something is
wrong. I thought that if a full backup was done that it
emptyed the transaction logs but that dies not appear to
be the case either and is why I have the transition logs
in the mainance plan. Any information on how to get the
old fikes to delete?
Here is a good summary of the normal issues related to this by Bill from MS:
http://support.microsoft.com/default...;en-us;Q303292
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Andrew J. Kelly SQL MVP
"Jim Abel" <jim.abel@.lmco.com> wrote in message
news:177f01c49cbe$504699e0$a301280a@.phx.gbl...
> I have a maintanace Plan establishe that is working excep
> for on nagging item. The plan does both full backups and
> transaction log backups each day. It is supposed to
> delete files older than 3 days old but does not. I have
> to manually go and clear the old files on a regular basis
> to keep from filling up the disk. I have not seen any
> error or know what to look for to see if something is
> wrong. I thought that if a full backup was done that it
> emptyed the transaction logs but that dies not appear to
> be the case either and is why I have the transition logs
> in the mainance plan. Any information on how to get the
> old fikes to delete?
|||i had the same problem. RIght-click on the maintenance plan and look at the
job history for any errors.
The problem I had was someone set up a maintenance plan to backup ALL
databases and to do transaction lo backups periodically. The trouble with
that is the system DBs (and any user DBs that are not set to FULL recovery
mode) cannot have Transaction log backups performed on them. So the Backups
were running, but the delete step was not running because the transaction log
backup step failed for some of the DBs.
hope that helps
"Andrew J. Kelly" wrote:

> Here is a good summary of the normal issues related to this by Bill from MS:
>
> http://support.microsoft.com/default...;en-us;Q303292
> This is likely to be either a permissions problem or a sharing violation
> problem. The maintenance plan is run as a job, and jobs are run by the
> SQLServerAgent service.
> Permissions:
> 1. Determine the startup account for the SQLServerAgent service
> (Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
> account is the security context for jobs, and thus the maintenance plan.
> 2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
> account) then skip step 3.
> 3. On that box, log onto NT as that account. Using Explorer, attempt to
> delete an expired backup. If that succeeds then go to Sharing Violation
> section.
> 4. Log onto NT with an account that is an administrator and use Explorer to
> look at the Properties|Security of the folder (where the backups reside)
> and ensure the SQLServerAgent startup account has Full Control. If the
> SQLServerAgent startup account is LocalSystem, then the account to consider
> is SYSTEM.
> 5. In NT, if an account is a member of an NT group, and if that group has
> Access is Denied, then that account will have Access is Denied, even if
> that account is also a member of the Administrators group. Thus you may
> need to check group permissions (if the Startup Account is a member of a
> group).
> 6. Keep in mind that permissions (by default) are inherited from a parent
> folder. Thus, if the backups are stored in C:\bak, and if someone had
> denied permission to the SQLServerAgent startup account for C:\, then
> C:\bak will inherit access is denied.
> Sharing violation:
> This is likely to be rooted in a timing issue, with the most likely cause
> being another scheduled process (such as NT Backup or Anti-Virus software)
> having the backup file open at the time when the SQLServerAgent (i.e., the
> maintenance plan job) tried to delete it.
> 1. Download filemon and handle from www.sysinternals.com.
> 2. I am not sure whether filemon can be scheduled, or you might be able to
> use NT scheduling services to start filemon just before the maintenance
> plan job is started, but the filemon log can become very large, so it would
> be best to start it some short time before the maintenance plan starts.
> 3. Inspect the filemon log for another process that has that backup file
> open (if your lucky enough to have started filemon before this other
> process grabs the backup folder), and inspect the log for the results when
> the SQLServerAgent agent attempts to open that same file.
> 4. Schedule the job or that other process to do their work at different
> times.
> 5. You can use the handle utility if you are around at the time when the
> job is scheduled to run.
> If the backup files are going to a \\share or a mapped drive (as opposed to
> local drive), then you will need to modify the above (with respect to where
> the tests and utilities are run).
> Finally, inspection of the maintenance plan's history report might be
> useful.
> Thanks,
> Bill Hollinshead
> Microsoft, SQL Server
>
> --
> Andrew J. Kelly SQL MVP
>
> "Jim Abel" <jim.abel@.lmco.com> wrote in message
> news:177f01c49cbe$504699e0$a301280a@.phx.gbl...
>
>

Mantanace Plan not deleting old files

I have a maintanace Plan establishe that is working excep
for on nagging item. The plan does both full backups and
transaction log backups each day. It is supposed to
delete files older than 3 days old but does not. I have
to manually go and clear the old files on a regular basis
to keep from filling up the disk. I have not seen any
error or know what to look for to see if something is
wrong. I thought that if a full backup was done that it
emptyed the transaction logs but that dies not appear to
be the case either and is why I have the transition logs
in the mainance plan. Any information on how to get the
old fikes to delete?Here is a good summary of the normal issues related to this by Bill from MS:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q303292
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Andrew J. Kelly SQL MVP
"Jim Abel" <jim.abel@.lmco.com> wrote in message
news:177f01c49cbe$504699e0$a301280a@.phx.gbl...
> I have a maintanace Plan establishe that is working excep
> for on nagging item. The plan does both full backups and
> transaction log backups each day. It is supposed to
> delete files older than 3 days old but does not. I have
> to manually go and clear the old files on a regular basis
> to keep from filling up the disk. I have not seen any
> error or know what to look for to see if something is
> wrong. I thought that if a full backup was done that it
> emptyed the transaction logs but that dies not appear to
> be the case either and is why I have the transition logs
> in the mainance plan. Any information on how to get the
> old fikes to delete?|||i had the same problem. RIght-click on the maintenance plan and look at the
job history for any errors.
The problem I had was someone set up a maintenance plan to backup ALL
databases and to do transaction lo backups periodically. The trouble with
that is the system DBs (and any user DBs that are not set to FULL recovery
mode) cannot have Transaction log backups performed on them. So the Backups
were running, but the delete step was not running because the transaction log
backup step failed for some of the DBs.
hope that helps
"Andrew J. Kelly" wrote:
> Here is a good summary of the normal issues related to this by Bill from MS:
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q303292
> This is likely to be either a permissions problem or a sharing violation
> problem. The maintenance plan is run as a job, and jobs are run by the
> SQLServerAgent service.
> Permissions:
> 1. Determine the startup account for the SQLServerAgent service
> (Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
> account is the security context for jobs, and thus the maintenance plan.
> 2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
> account) then skip step 3.
> 3. On that box, log onto NT as that account. Using Explorer, attempt to
> delete an expired backup. If that succeeds then go to Sharing Violation
> section.
> 4. Log onto NT with an account that is an administrator and use Explorer to
> look at the Properties|Security of the folder (where the backups reside)
> and ensure the SQLServerAgent startup account has Full Control. If the
> SQLServerAgent startup account is LocalSystem, then the account to consider
> is SYSTEM.
> 5. In NT, if an account is a member of an NT group, and if that group has
> Access is Denied, then that account will have Access is Denied, even if
> that account is also a member of the Administrators group. Thus you may
> need to check group permissions (if the Startup Account is a member of a
> group).
> 6. Keep in mind that permissions (by default) are inherited from a parent
> folder. Thus, if the backups are stored in C:\bak, and if someone had
> denied permission to the SQLServerAgent startup account for C:\, then
> C:\bak will inherit access is denied.
> Sharing violation:
> This is likely to be rooted in a timing issue, with the most likely cause
> being another scheduled process (such as NT Backup or Anti-Virus software)
> having the backup file open at the time when the SQLServerAgent (i.e., the
> maintenance plan job) tried to delete it.
> 1. Download filemon and handle from www.sysinternals.com.
> 2. I am not sure whether filemon can be scheduled, or you might be able to
> use NT scheduling services to start filemon just before the maintenance
> plan job is started, but the filemon log can become very large, so it would
> be best to start it some short time before the maintenance plan starts.
> 3. Inspect the filemon log for another process that has that backup file
> open (if your lucky enough to have started filemon before this other
> process grabs the backup folder), and inspect the log for the results when
> the SQLServerAgent agent attempts to open that same file.
> 4. Schedule the job or that other process to do their work at different
> times.
> 5. You can use the handle utility if you are around at the time when the
> job is scheduled to run.
> If the backup files are going to a \\share or a mapped drive (as opposed to
> local drive), then you will need to modify the above (with respect to where
> the tests and utilities are run).
> Finally, inspection of the maintenance plan's history report might be
> useful.
> Thanks,
> Bill Hollinshead
> Microsoft, SQL Server
>
> --
> Andrew J. Kelly SQL MVP
>
> "Jim Abel" <jim.abel@.lmco.com> wrote in message
> news:177f01c49cbe$504699e0$a301280a@.phx.gbl...
> > I have a maintanace Plan establishe that is working excep
> > for on nagging item. The plan does both full backups and
> > transaction log backups each day. It is supposed to
> > delete files older than 3 days old but does not. I have
> > to manually go and clear the old files on a regular basis
> > to keep from filling up the disk. I have not seen any
> > error or know what to look for to see if something is
> > wrong. I thought that if a full backup was done that it
> > emptyed the transaction logs but that dies not appear to
> > be the case either and is why I have the transition logs
> > in the mainance plan. Any information on how to get the
> > old fikes to delete?
>
>

Wednesday, March 7, 2012

Managing multiple SQL Server databases

Hi,

I have to manage many SQL Server databases on several servers. How can I manage the jobs, backups and the space on the disc without going to each and every server and database and job? Is there any script to run this? It will be very helpful if you can provide me the sample script or point me to any web site where I can get the info/script for this. Thanks in advance...

My preferable way to do this is to create the job on the server, script it out, parameterize it and deploy it with changed parameters on the other servers, this is also very helpful as you can tweak the paths to the log files, as they can differ from server to server as well as in the drive location as in the path.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||

When running scripts to manage the system you are going to have to run them on the server they are needed on... Even if they are stored on the one server. I would start by looking at Linked Servers so that you can run your queries and scripts on the remote machines from the one server. In regards to monitoring the servers you could also look at MOM (Microsoft Operations Manager) and have the agents installed on each of your SQL Servers. This way the MOM System can monitor the OS Level parameters as well as some of the SQL Systems (Using the SQL Management Packs). At the same time you can also create custom scripts and tasks that MOM Can run that can be targeted to use the different servers.

With SSIS You should be able to also confugre your SQL Jobs to run from the one server and execute the different commands on the different servers.

|||

For Multiserver administration u need to create

Master server

Target Server

Enlist Traget server ................

See http://msdn2.microsoft.com/en-us/library/ms191305.aspx

I hope this helps

|||Thank you Jens, Glenn and admindba for your valuable inputs...