Long running backups

I've got a server (SQL 2K, Win2K) where the backups
have started running long.

The database is a bit largish -- 150GB or so. Up until
last month, the backups were taking on the order of
4 to 5 hours -- depending on the level of activity on the
server.

I'm using a T-SQL script in the SQLAgent to run the
backups. Native SQL backup to an AIT tape drive.

Now, for no apparent reason, the backups are taking
on the order of 24 to 26 hours. The backups complete
successfully -- no errors, just taking an outrageously
long time to complete. DBCCs check out AOK, no
problems with the database.

No changes to the machine. No hardware changes. No
software changes. Weird.

Multiple tape media have been tried -- it's not a case
of a tape going bad.

We've had no problems with this box for almost 4
years. Now it's gettin' jiggy with us!

Any ideas on where to start with this one?

Thanks in advance.I once had a server with sporadic slowness backing up to SCSI DLT. It would
work fine for a view weeks and turn slow for no apparent reason. The only
workaround was to cold boot the server, including the tape device, so it was
probably a hardware issue. Check the Windows event log to see if you have
related messages.

You might consider backing up to disk and then archiving the disk backups to
tape. You can greatly reduce the backup time and space requirements with
the third party SQL LiteSpeed product http://www.dbassociatesit.com/.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Sgt. Sausage" <nobody@.nowhere.com> wrote in message
news:402c18d5$0$52145$a0465688@.nnrp.fuse.net...
> I've got a server (SQL 2K, Win2K) where the backups
> have started running long.
> The database is a bit largish -- 150GB or so. Up until
> last month, the backups were taking on the order of
> 4 to 5 hours -- depending on the level of activity on the
> server.
> I'm using a T-SQL script in the SQLAgent to run the
> backups. Native SQL backup to an AIT tape drive.
> Now, for no apparent reason, the backups are taking
> on the order of 24 to 26 hours. The backups complete
> successfully -- no errors, just taking an outrageously
> long time to complete. DBCCs check out AOK, no
> problems with the database.
> No changes to the machine. No hardware changes. No
> software changes. Weird.
> Multiple tape media have been tried -- it's not a case
> of a tape going bad.
> We've had no problems with this box for almost 4
> years. Now it's gettin' jiggy with us!
> Any ideas on where to start with this one?
> Thanks in advance.

Long Backups with SQL Agent

We use Omniback for a backup solution. However most of the time, we could
not restore a database from the backups. We changed our strategy last week
to have the SQL Agent to backup all of the SQL Severs to a central location
and have Omniback backup the files.
Omniback took about an hour to backup a 1gig+ database. Here is the log file.
Database backed up: Database: pdi_warehouse_001_001, creation date(time):
2004/05/17(18:29:34), pages dumped: 18105899, first LSN: 5111210:44:1, last
LSN: 5111210:327:1, number of dump devices: 1, device information: (FILE=1,
TYPE=VIRTUAL_DEVICE: {'Data
Protector_(DEFAULT)_pdi_warehouse_001_001_17_36_36 '}).
Now, the same database took approximately 10 hours to back up last night.
Here is the log file.
Database backed up: Database: pdi_warehouse_001_001, creation date(time):
2004/05/17(18:29:34), pages dumped: 18546755, first LSN: 5143133:52:1, last
LSN: 5148376:689:1, number of dump devices: 1, device information: (FILE=1,
TYPE=DISK:
{'\\co-ap-08\SqlBkups\FOCALPOINT_pdi_warehouse_001_001_20070 4111705.BAK'}).
Why so log when using the SQL Agent? There is a 1 gig connection from the
sql server to the backup media. Any suggestion will be appreciated.
brymer28303 wrote:
> We use Omniback for a backup solution. However most of the time, we could
> not restore a database from the backups. We changed our strategy last week
> to have the SQL Agent to backup all of the SQL Severs to a central location
> and have Omniback backup the files.
> Omniback took about an hour to backup a 1gig+ database. Here is the log file.
> Database backed up: Database: pdi_warehouse_001_001, creation date(time):
> 2004/05/17(18:29:34), pages dumped: 18105899, first LSN: 5111210:44:1, last
> LSN: 5111210:327:1, number of dump devices: 1, device information: (FILE=1,
> TYPE=VIRTUAL_DEVICE: {'Data
> Protector_(DEFAULT)_pdi_warehouse_001_001_17_36_36 '}).
> Now, the same database took approximately 10 hours to back up last night.
> Here is the log file.
> Database backed up: Database: pdi_warehouse_001_001, creation date(time):
> 2004/05/17(18:29:34), pages dumped: 18546755, first LSN: 5143133:52:1, last
> LSN: 5148376:689:1, number of dump devices: 1, device information: (FILE=1,
> TYPE=DISK:
> {'\\co-ap-08\SqlBkups\FOCALPOINT_pdi_warehouse_001_001_20070 4111705.BAK'}).
> Why so log when using the SQL Agent? There is a 1 gig connection from the
> sql server to the backup media. Any suggestion will be appreciated.
>
Hi,
Have you tried running the backup to a local disk in order to rule out
network issues? 10 hours for doing a 1 GB database backup is definitely
far too long, so something must have gone wrong. The backup destination
for the 2 backup scenarios seems to be different, so I think you should
start looking here.
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
|||Thanks Steen. Since this post, we have started received network error 64.
This gives us a place to look.
""Steen Schlüter Persson (DK)"" wrote:

> brymer28303 wrote:
> Hi,
> Have you tried running the backup to a local disk in order to rule out
> network issues? 10 hours for doing a 1 GB database backup is definitely
> far too long, so something must have gone wrong. The backup destination
> for the 2 backup scenarios seems to be different, so I think you should
> start looking here.
> --
> Regards
> Steen Schlüter Persson
> Database Administrator / System Administrator
>

Long Backups with SQL Agent

We use Omniback for a backup solution. However most of the time, we could
not restore a database from the backups. We changed our strategy last week
to have the SQL Agent to backup all of the SQL Severs to a central location
and have Omniback backup the files.
Omniback took about an hour to backup a 1gig+ database. Here is the log file.
Database backed up: Database: pdi_warehouse_001_001, creation date(time):
2004/05/17(18:29:34), pages dumped: 18105899, first LSN: 5111210:44:1, last
LSN: 5111210:327:1, number of dump devices: 1, device information: (FILE=1,
TYPE=VIRTUAL_DEVICE: {'Data
Protector_(DEFAULT)_pdi_warehouse_001_001_17_36_36'}).
Now, the same database took approximately 10 hours to back up last night.
Here is the log file.
Database backed up: Database: pdi_warehouse_001_001, creation date(time):
2004/05/17(18:29:34), pages dumped: 18546755, first LSN: 5143133:52:1, last
LSN: 5148376:689:1, number of dump devices: 1, device information: (FILE=1,
TYPE=DISK:
{'\\co-ap-08\SqlBkups\FOCALPOINT_pdi_warehouse_001_001_200704111705.BAK'}).
Why so log when using the SQL Agent? There is a 1 gig connection from the
sql server to the backup media. Any suggestion will be appreciated.brymer28303 wrote:
> We use Omniback for a backup solution. However most of the time, we could
> not restore a database from the backups. We changed our strategy last week
> to have the SQL Agent to backup all of the SQL Severs to a central location
> and have Omniback backup the files.
> Omniback took about an hour to backup a 1gig+ database. Here is the log file.
> Database backed up: Database: pdi_warehouse_001_001, creation date(time):
> 2004/05/17(18:29:34), pages dumped: 18105899, first LSN: 5111210:44:1, last
> LSN: 5111210:327:1, number of dump devices: 1, device information: (FILE=1,
> TYPE=VIRTUAL_DEVICE: {'Data
> Protector_(DEFAULT)_pdi_warehouse_001_001_17_36_36'}).
> Now, the same database took approximately 10 hours to back up last night.
> Here is the log file.
> Database backed up: Database: pdi_warehouse_001_001, creation date(time):
> 2004/05/17(18:29:34), pages dumped: 18546755, first LSN: 5143133:52:1, last
> LSN: 5148376:689:1, number of dump devices: 1, device information: (FILE=1,
> TYPE=DISK:
> {'\\co-ap-08\SqlBkups\FOCALPOINT_pdi_warehouse_001_001_200704111705.BAK'}).
> Why so log when using the SQL Agent? There is a 1 gig connection from the
> sql server to the backup media. Any suggestion will be appreciated.
>
Hi,
Have you tried running the backup to a local disk in order to rule out
network issues? 10 hours for doing a 1 GB database backup is definitely
far too long, so something must have gone wrong. The backup destination
for the 2 backup scenarios seems to be different, so I think you should
start looking here.
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator|||Thanks Steen. Since this post, we have started received network error 64.
This gives us a place to look.
""Steen Schlüter Persson (DK)"" wrote:
> brymer28303 wrote:
> > We use Omniback for a backup solution. However most of the time, we could
> > not restore a database from the backups. We changed our strategy last week
> > to have the SQL Agent to backup all of the SQL Severs to a central location
> > and have Omniback backup the files.
> >
> > Omniback took about an hour to backup a 1gig+ database. Here is the log file.
> >
> > Database backed up: Database: pdi_warehouse_001_001, creation date(time):
> > 2004/05/17(18:29:34), pages dumped: 18105899, first LSN: 5111210:44:1, last
> > LSN: 5111210:327:1, number of dump devices: 1, device information: (FILE=1,
> > TYPE=VIRTUAL_DEVICE: {'Data
> > Protector_(DEFAULT)_pdi_warehouse_001_001_17_36_36'}).
> >
> > Now, the same database took approximately 10 hours to back up last night.
> > Here is the log file.
> >
> > Database backed up: Database: pdi_warehouse_001_001, creation date(time):
> > 2004/05/17(18:29:34), pages dumped: 18546755, first LSN: 5143133:52:1, last
> > LSN: 5148376:689:1, number of dump devices: 1, device information: (FILE=1,
> > TYPE=DISK:
> > {'\\co-ap-08\SqlBkups\FOCALPOINT_pdi_warehouse_001_001_200704111705.BAK'}).
> >
> > Why so log when using the SQL Agent? There is a 1 gig connection from the
> > sql server to the backup media. Any suggestion will be appreciated.
> >
> Hi,
> Have you tried running the backup to a local disk in order to rule out
> network issues? 10 hours for doing a 1 GB database backup is definitely
> far too long, so something must have gone wrong. The backup destination
> for the 2 backup scenarios seems to be different, so I think you should
> start looking here.
> --
> Regards
> Steen Schlüter Persson
> Database Administrator / System Administrator
>

Long Backups with SQL Agent

We use Omniback for a backup solution. However most of the time, we could
not restore a database from the backups. We changed our strategy last week
to have the SQL Agent to backup all of the SQL Severs to a central location
and have Omniback backup the files.
Omniback took about an hour to backup a 1gig+ database. Here is the log fil
e.
Database backed up: Database: pdi_warehouse_001_001, creation date(time):
2004/05/17(18:29:34), pages dumped: 18105899, first LSN: 5111210:44:1, last
LSN: 5111210:327:1, number of dump devices: 1, device information: (FILE=1,
TYPE=VIRTUAL_DEVICE: {'Data
Protector_(DEFAULT)_pdi_warehouse_001_00
1_17_36_36'}).
Now, the same database took approximately 10 hours to back up last night.
Here is the log file.
Database backed up: Database: pdi_warehouse_001_001, creation date(time):
2004/05/17(18:29:34), pages dumped: 18546755, first LSN: 5143133:52:1, last
LSN: 5148376:689:1, number of dump devices: 1, device information: (FILE=1,
TYPE=DISK:
{'\\co-ap- 08\SqlBkups\FOCALPOINT_pdi_warehouse_001
_001_200704111705.BAK
'}).
Why so log when using the SQL Agent? There is a 1 gig connection from the
sql server to the backup media. Any suggestion will be appreciated.brymer28303 wrote:
> We use Omniback for a backup solution. However most of the time, we could
> not restore a database from the backups. We changed our strategy last wee
k
> to have the SQL Agent to backup all of the SQL Severs to a central locatio
n
> and have Omniback backup the files.
> Omniback took about an hour to backup a 1gig+ database. Here is the log f
ile.
> Database backed up: Database: pdi_warehouse_001_001, creation date(time):
> 2004/05/17(18:29:34), pages dumped: 18105899, first LSN: 5111210:44:1, las
t
> LSN: 5111210:327:1, number of dump devices: 1, device information: (FILE=1
,
> TYPE=VIRTUAL_DEVICE: {'Data
> Protector_(DEFAULT)_pdi_warehouse_001_00
1_17_36_36'}).
> Now, the same database took approximately 10 hours to back up last night.
> Here is the log file.
> Database backed up: Database: pdi_warehouse_001_001, creation date(time):
> 2004/05/17(18:29:34), pages dumped: 18546755, first LSN: 5143133:52:1, las
t
> LSN: 5148376:689:1, number of dump devices: 1, device information: (FILE=1
,
> TYPE=DISK:
> {'\\co-ap- 08\SqlBkups\FOCALPOINT_pdi_warehouse_001
_001_200704111705.B
AK'}).
> Why so log when using the SQL Agent? There is a 1 gig connection from the
> sql server to the backup media. Any suggestion will be appreciated.
>
Hi,
Have you tried running the backup to a local disk in order to rule out
network issues? 10 hours for doing a 1 GB database backup is definitely
far too long, so something must have gone wrong. The backup destination
for the 2 backup scenarios seems to be different, so I think you should
start looking here.
Regards
Steen Schlüter Persson
Database Administrator / System Administrator|||Thanks Steen. Since this post, we have started received network error 64.
This gives us a place to look.
""Steen Schlüter Persson (DK)"" wrote:

> brymer28303 wrote:
> Hi,
> Have you tried running the backup to a local disk in order to rule out
> network issues? 10 hours for doing a 1 GB database backup is definitely
> far too long, so something must have gone wrong. The backup destination
> for the 2 backup scenarios seems to be different, so I think you should
> start looking here.
> --
> Regards
> Steen Schlüter Persson
> Database Administrator / System Administrator
>sql

long backup duration

I recently moved my backups from the wizard generated maintenance plans to a
simple backup script. My 180GB database is now taking 7 hours to backup with
instead of the normal 4 hours. The step details show 7.359 MB/sec when the
backup completes in 7 hours and 12.453 MB/sec when the backup completes in 4
hours.
Below is my script. This is actually step 2. Step 1 deletes the previous
backup.
BACKUP DATABASE MyDB
TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
WITH INIT
During the backup, pinging the NAS device from the SQL Server takes 0ms.
I have used Perfmon and the counters seem usual from what I have researched
(e.g., http://www.sql-server-performance.co...ore_tuning.asp).
Average Device Throughput bytes/sec: 5570346
Average % Disk Time: 3.854
Average Disk Queue Length: .0193
Average IO Write Bytes/sec: 5897638
Average Split IO/sec: 0
As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent -
Alert Engine.
No compression is taking place on either machine.
Does anyone have any suggestions as what is causing the backup time to
almost double?
Thanks,
ray
SS2K
Hi,
Was your Wizard generated backup maintenance plan overwriting the same
backup file each time or writing to a new file each time? The only
thing I can think of is that if the backup file already exists and you
are re-initializing it takes less time. From an OS/Network standpoint
that should not hinder performance. Perhaps you can look at the wizard
generated backup plan to see if there are some option enabled by SQL
Server which may increase performance.
Shahryar
raybouk wrote:

>I recently moved my backups from the wizard generated maintenance plans to a
>simple backup script. My 180GB database is now taking 7 hours to backup with
>instead of the normal 4 hours. The step details show 7.359 MB/sec when the
>backup completes in 7 hours and 12.453 MB/sec when the backup completes in 4
>hours.
>Below is my script. This is actually step 2. Step 1 deletes the previous
>backup.
>BACKUP DATABASE MyDB
>TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
>WITH INIT
>During the backup, pinging the NAS device from the SQL Server takes 0ms.
>I have used Perfmon and the counters seem usual from what I have researched
>(e.g., http://www.sql-server-performance.co...ore_tuning.asp).
>Average Device Throughput bytes/sec: 5570346
>Average % Disk Time: 3.854
>Average Disk Queue Length: .0193
>Average IO Write Bytes/sec: 5897638
>Average Split IO/sec: 0
>As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent -
>Alert Engine.
>No compression is taking place on either machine.
>Does anyone have any suggestions as what is causing the backup time to
>almost double?
>Thanks,
>ray
>SS2K
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is legally privileged. The information is solely for the use of the intended recipient(s); any disclosure, copying, distribution, or other use of this information is strictly prohi
bited. If you have received this e-mail in error, please notify the sender by return e-mail and delete this message. Thank you.
|||Delete the old backup file prior to performing the backup. Dont init the new
backup device. I found this to work the best.
On a sidenote, ping rates do not necessarily reflect thoughput performance.
"raybouk" wrote:

> I recently moved my backups from the wizard generated maintenance plans to a
> simple backup script. My 180GB database is now taking 7 hours to backup with
> instead of the normal 4 hours. The step details show 7.359 MB/sec when the
> backup completes in 7 hours and 12.453 MB/sec when the backup completes in 4
> hours.
> Below is my script. This is actually step 2. Step 1 deletes the previous
> backup.
> BACKUP DATABASE MyDB
> TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
> WITH INIT
> During the backup, pinging the NAS device from the SQL Server takes 0ms.
> I have used Perfmon and the counters seem usual from what I have researched
> (e.g., http://www.sql-server-performance.co...ore_tuning.asp).
> Average Device Throughput bytes/sec: 5570346
> Average % Disk Time: 3.854
> Average Disk Queue Length: .0193
> Average IO Write Bytes/sec: 5897638
> Average Split IO/sec: 0
> As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent -
> Alert Engine.
> No compression is taking place on either machine.
> Does anyone have any suggestions as what is causing the backup time to
> almost double?
> Thanks,
> ray
> SS2K
|||What was the destination of the Wizard generated backups?
There is going to be a world of difference between writing to a local disk
vs going to a NAS device.
You should be able to go into the Management Studio and look at the script
that it generates.
See what the differences are in the backup statement.
"Raoul Laoyan" <RaoulLaoyan@.discussions.microsoft.com> wrote in message
news:0C4A91B3-D06B-40DA-87EE-1D94A94A707F@.microsoft.com...[vbcol=seagreen]
> Delete the old backup file prior to performing the backup. Dont init the
> new
> backup device. I found this to work the best.
> On a sidenote, ping rates do not necessarily reflect thoughput
> performance.
> "raybouk" wrote:

long backup duration

I recently moved my backups from the wizard generated maintenance plans to a
simple backup script. My 180GB database is now taking 7 hours to backup with
instead of the normal 4 hours. The step details show 7.359 MB/sec when the
backup completes in 7 hours and 12.453 MB/sec when the backup completes in 4
hours.
Below is my script. This is actually step 2. Step 1 deletes the previous
backup.
BACKUP DATABASE MyDB
TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
WITH INIT
During the backup, pinging the NAS device from the SQL Server takes 0ms.
I have used Perfmon and the counters seem usual from what I have researched
(e.g., http://www.sql-server-performance.c...tore_tuning.asp).
Average Device Throughput bytes/sec: 5570346
Average % Disk Time: 3.854
Average Disk Queue Length: .0193
Average IO Write Bytes/sec: 5897638
Average Split IO/sec: 0
As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent -
Alert Engine.
No compression is taking place on either machine.
Does anyone have any suggestions as what is causing the backup time to
almost double?
Thanks,
ray
SS2KHi,
Was your Wizard generated backup maintenance plan overwriting the same
backup file each time or writing to a new file each time? The only
thing I can think of is that if the backup file already exists and you
are re-initializing it takes less time. From an OS/Network standpoint
that should not hinder performance. Perhaps you can look at the wizard
generated backup plan to see if there are some option enabled by SQL
Server which may increase performance.
Shahryar
raybouk wrote:

>I recently moved my backups from the wizard generated maintenance plans to
a
>simple backup script. My 180GB database is now taking 7 hours to backup wit
h
>instead of the normal 4 hours. The step details show 7.359 MB/sec when the
>backup completes in 7 hours and 12.453 MB/sec when the backup completes in
4
>hours.
>Below is my script. This is actually step 2. Step 1 deletes the previous
>backup.
>BACKUP DATABASE MyDB
>TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
>WITH INIT
>During the backup, pinging the NAS device from the SQL Server takes 0ms.
>I have used Perfmon and the counters seem usual from what I have researched
>(e.g., http://www.sql-server-performance.c...tore_tuning.asp).
>Average Device Throughput bytes/sec: 5570346
>Average % Disk Time: 3.854
>Average Disk Queue Length: .0193
>Average IO Write Bytes/sec: 5897638
>Average Split IO/sec: 0
>As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent
-
>Alert Engine.
>No compression is taking place on either machine.
>Does anyone have any suggestions as what is causing the backup time to
>almost double?
>Thanks,
>ray
>SS2K
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is
legally privileged. The information is solely for the use of the intended
recipient(s); any disclosure, copying, distribution, or other use of this in
formation is strictly prohi
bited. If you have received this e-mail in error, please notify the sender
by return e-mail and delete this message. Thank you.|||Delete the old backup file prior to performing the backup. Dont init the ne
w
backup device. I found this to work the best.
On a sidenote, ping rates do not necessarily reflect thoughput performance.
"raybouk" wrote:

> I recently moved my backups from the wizard generated maintenance plans to
a
> simple backup script. My 180GB database is now taking 7 hours to backup wi
th
> instead of the normal 4 hours. The step details show 7.359 MB/sec when the
> backup completes in 7 hours and 12.453 MB/sec when the backup completes in
4
> hours.
> Below is my script. This is actually step 2. Step 1 deletes the previous
> backup.
> BACKUP DATABASE MyDB
> TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
> WITH INIT
> During the backup, pinging the NAS device from the SQL Server takes 0ms.
> I have used Perfmon and the counters seem usual from what I have researche
d
> (e.g., http://www.sql-server-performance.c...tore_tuning.asp).
> Average Device Throughput bytes/sec: 5570346
> Average % Disk Time: 3.854
> Average Disk Queue Length: .0193
> Average IO Write Bytes/sec: 5897638
> Average Split IO/sec: 0
> As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent
-
> Alert Engine.
> No compression is taking place on either machine.
> Does anyone have any suggestions as what is causing the backup time to
> almost double?
> Thanks,
> ray
> SS2K|||What was the destination of the Wizard generated backups?
There is going to be a world of difference between writing to a local disk
vs going to a NAS device.
You should be able to go into the Management Studio and look at the script
that it generates.
See what the differences are in the backup statement.
"Raoul Laoyan" <RaoulLaoyan@.discussions.microsoft.com> wrote in message
news:0C4A91B3-D06B-40DA-87EE-1D94A94A707F@.microsoft.com...[vbcol=seagreen]
> Delete the old backup file prior to performing the backup. Dont init the
> new
> backup device. I found this to work the best.
> On a sidenote, ping rates do not necessarily reflect thoughput
> performance.
> "raybouk" wrote:
>

long backup duration

I recently moved my backups from the wizard generated maintenance plans to a
simple backup script. My 180GB database is now taking 7 hours to backup with
instead of the normal 4 hours. The step details show 7.359 MB/sec when the
backup completes in 7 hours and 12.453 MB/sec when the backup completes in 4
hours.
Below is my script. This is actually step 2. Step 1 deletes the previous
backup.
BACKUP DATABASE MyDB
TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
WITH INIT
During the backup, pinging the NAS device from the SQL Server takes 0ms.
I have used Perfmon and the counters seem usual from what I have researched
(e.g., http://www.sql-server-performance.com/backup_restore_tuning.asp).
Average Device Throughput bytes/sec: 5570346
Average % Disk Time: 3.854
Average Disk Queue Length: .0193
Average IO Write Bytes/sec: 5897638
Average Split IO/sec: 0
As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent -
Alert Engine.
No compression is taking place on either machine.
Does anyone have any suggestions as what is causing the backup time to
almost double?
Thanks,
ray
SS2KHi,
Was your Wizard generated backup maintenance plan overwriting the same
backup file each time or writing to a new file each time? The only
thing I can think of is that if the backup file already exists and you
are re-initializing it takes less time. From an OS/Network standpoint
that should not hinder performance. Perhaps you can look at the wizard
generated backup plan to see if there are some option enabled by SQL
Server which may increase performance.
Shahryar
raybouk wrote:
>I recently moved my backups from the wizard generated maintenance plans to a
>simple backup script. My 180GB database is now taking 7 hours to backup with
>instead of the normal 4 hours. The step details show 7.359 MB/sec when the
>backup completes in 7 hours and 12.453 MB/sec when the backup completes in 4
>hours.
>Below is my script. This is actually step 2. Step 1 deletes the previous
>backup.
>BACKUP DATABASE MyDB
>TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
>WITH INIT
>During the backup, pinging the NAS device from the SQL Server takes 0ms.
>I have used Perfmon and the counters seem usual from what I have researched
>(e.g., http://www.sql-server-performance.com/backup_restore_tuning.asp).
>Average Device Throughput bytes/sec: 5570346
>Average % Disk Time: 3.854
>Average Disk Queue Length: .0193
>Average IO Write Bytes/sec: 5897638
>Average Split IO/sec: 0
>As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent -
>Alert Engine.
>No compression is taking place on either machine.
>Does anyone have any suggestions as what is causing the backup time to
>almost double?
>Thanks,
>ray
>SS2K
>
Shahryar G. Hashemi | Sr. DBA Consultant
InfoSpace, Inc.
601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 USA
Mobile +1 206.459.6203 | Office +1 425.201.8853 | Fax +1 425.201.6150
shashem@.infospace.com | www.infospaceinc.com
This e-mail and any attachments may contain confidential information that is legally privileged. The information is solely for the use of the intended recipient(s); any disclosure, copying, distribution, or other use of this information is strictly prohibited. If you have received this e-mail in error, please notify the sender by return e-mail and delete this message. Thank you.|||Delete the old backup file prior to performing the backup. Dont init the new
backup device. I found this to work the best.
On a sidenote, ping rates do not necessarily reflect thoughput performance.
"raybouk" wrote:
> I recently moved my backups from the wizard generated maintenance plans to a
> simple backup script. My 180GB database is now taking 7 hours to backup with
> instead of the normal 4 hours. The step details show 7.359 MB/sec when the
> backup completes in 7 hours and 12.453 MB/sec when the backup completes in 4
> hours.
> Below is my script. This is actually step 2. Step 1 deletes the previous
> backup.
> BACKUP DATABASE MyDB
> TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
> WITH INIT
> During the backup, pinging the NAS device from the SQL Server takes 0ms.
> I have used Perfmon and the counters seem usual from what I have researched
> (e.g., http://www.sql-server-performance.com/backup_restore_tuning.asp).
> Average Device Throughput bytes/sec: 5570346
> Average % Disk Time: 3.854
> Average Disk Queue Length: .0193
> Average IO Write Bytes/sec: 5897638
> Average Split IO/sec: 0
> As for sp_who2, the only thing peculiar is a DISKIO of 875659 for SQLAgent -
> Alert Engine.
> No compression is taking place on either machine.
> Does anyone have any suggestions as what is causing the backup time to
> almost double?
> Thanks,
> ray
> SS2K|||What was the destination of the Wizard generated backups?
There is going to be a world of difference between writing to a local disk
vs going to a NAS device.
You should be able to go into the Management Studio and look at the script
that it generates.
See what the differences are in the backup statement.
"Raoul Laoyan" <RaoulLaoyan@.discussions.microsoft.com> wrote in message
news:0C4A91B3-D06B-40DA-87EE-1D94A94A707F@.microsoft.com...
> Delete the old backup file prior to performing the backup. Dont init the
> new
> backup device. I found this to work the best.
> On a sidenote, ping rates do not necessarily reflect thoughput
> performance.
> "raybouk" wrote:
>> I recently moved my backups from the wizard generated maintenance plans
>> to a
>> simple backup script. My 180GB database is now taking 7 hours to backup
>> with
>> instead of the normal 4 hours. The step details show 7.359 MB/sec when
>> the
>> backup completes in 7 hours and 12.453 MB/sec when the backup completes
>> in 4
>> hours.
>> Below is my script. This is actually step 2. Step 1 deletes the previous
>> backup.
>> BACKUP DATABASE MyDB
>> TO DISK = '\\MyNAS\sql\server\MyDB\MyDB.bak'
>> WITH INIT
>> During the backup, pinging the NAS device from the SQL Server takes 0ms.
>> I have used Perfmon and the counters seem usual from what I have
>> researched
>> (e.g., http://www.sql-server-performance.com/backup_restore_tuning.asp).
>> Average Device Throughput bytes/sec: 5570346
>> Average % Disk Time: 3.854
>> Average Disk Queue Length: .0193
>> Average IO Write Bytes/sec: 5897638
>> Average Split IO/sec: 0
>> As for sp_who2, the only thing peculiar is a DISKIO of 875659 for
>> SQLAgent -
>> Alert Engine.
>> No compression is taking place on either machine.
>> Does anyone have any suggestions as what is causing the backup time to
>> almost double?
>> Thanks,
>> ray
>> SS2K

Logshipping problem with naming transaction log backups

Hey, my logshipping is working just fine but the name of the backup file is of a concern to me. It's using the name in the format of DbName_20061011200002.trn. I know 20061011 is the date. That's fine. 2000 is supposed to be the time but it's giving the wrong time. It's supposed to be 1500 because the time right now is 3pm. And I dont know why the last 2 digits before the .trn are for. Is this something new in SQL 2005 logshipping? SQL 2000 didn't have it. Thank you.

Log shipping uses UTC time when naming the files. This ensures that global deployments of log shipping work consistently.

Regards,

Matt Hollingsworth

Sr. Program Manager

Microsoft SQL Server

|||Is there any possibility for me to change the naming convention. I wanted to go back to SQL 2000 naming convention. Please let me know. Thank you for your help.|||

You can use VBScript to rename your transaction log files to your requirements. Here's a sample script I use:

'============================
'Script to change a filename using timestamps
strMonth = DatePart("m", Now())
strDay = DatePart("d",Now())

if Len(strMonth)=1 then
strMonth = "0" & strMonth
else
strMonth = strMonth
end if

if Len(strDay)=1 then
strDay = "0" & strDay
else
strDay = strDay
end if

strFileName = "LOG_" & DatePart("yyyy",Now()) & strMonth & strDay & FormatDateTime(Now(), vbShortTime) & ".TRN"
strFileName = Replace(strFileName,":","")

Set objFSO = CreateObject("Scripting.FileSystemObject")
'===============================================
'Change the drive letter, folder and filename if necessary
objFSO.MoveFile "D:\SQL_Backups\LOG.TRN" , "D:\SQL_Backups\" & strFileName

You can include this in your Log Shipping Jobs on both the source and the destination servers. One thing to note is that the names should be the same as what you created when the transaction logs are restored on the destination. Your Database maintenance plan won't work on this. Might as well use a customized log shipping plan.

logshipping

Hi,
I'll take FULL and transaction LOG backups via a custom written stored
procedure.
But its working only for single database file. Does not dynamically pick up
database files/filegroups from the backup files themselves.
Is it possible to take backup of database contain files/filegroups?
I used this code in stored procedure:
BACKUP DATABASE @.db_name TO @.vbackupdevice
WITH INIT, NAME=@.db_name, NOSKIP, STATS=10, DESCRIPTION=@.v_filename, NOFORMAT
Any help will be appreciated.
Kind Regards,
Melih.Yea maan, i think its very impressive,
bu i am away this technical issues for 3 months,
sorry maan.
I hope you will find more usefull solution technics..
Cihan.
"Melih" wrote:
> Hi,
> I'll take FULL and transaction LOG backups via a custom written stored
> procedure.
> But its working only for single database file. Does not dynamically pick up
> database files/filegroups from the backup files themselves.
> Is it possible to take backup of database contain files/filegroups?
> I used this code in stored procedure:
> BACKUP DATABASE @.db_name TO @.vbackupdevice
> WITH INIT, NAME=@.db_name, NOSKIP, STATS=10, DESCRIPTION=@.v_filename, NOFORMAT
>
> Any help will be appreciated.
> Kind Regards,
> Melih.
>|||Melih,
Your backup is probably working... Even when the database contains multiple
files, from one or more filegroups the backup file (given your command) will
contain all of this in a single backup file..
Do a small test , backup, then restore a multi-file database as a different
name. This should show you that things are working fine.
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
I support the Professional Association for SQL Server ( PASS) and it''s
community of SQL Professionals.
"Melih" wrote:
> Hi,
> I'll take FULL and transaction LOG backups via a custom written stored
> procedure.
> But its working only for single database file. Does not dynamically pick up
> database files/filegroups from the backup files themselves.
> Is it possible to take backup of database contain files/filegroups?
> I used this code in stored procedure:
> BACKUP DATABASE @.db_name TO @.vbackupdevice
> WITH INIT, NAME=@.db_name, NOSKIP, STATS=10, DESCRIPTION=@.v_filename, NOFORMAT
>
> Any help will be appreciated.
> Kind Regards,
> Melih.
>|||I tested and get result:
Database 'Exchange' does not exist. Check sysdatabases.
ALTER DATABASE statement failed.
Device activation error. The physical file name 'C:\DATABASES
SQL2K\Exchange_Data2_Data.NDF' may be incorrect.
Server: Msg 3156, Level 16, State 1, Line 1
File 'Exchange_Data2' cannot be restored to 'C:\DATABASES
SQL2K\Exchange_Data2_Data.NDF'. Use WITH MOVE to identify a valid location
for the file.
Server: Msg 5105, Level 16, State 1, Line 1
Device activation error. The physical file name 'C:\DATABASES
SQL2K\Exchange_Data3_Data.NDF' may be incorrect.
Server: Msg 3156, Level 16, State 1, Line 1
File 'Exchange_Data3' cannot be restored to 'C:\DATABASES
SQL2K\Exchange_Data3_Data.NDF'. Use WITH MOVE to identify a valid location
for the file.
Server: Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
I used this code in stored procedure:
set @.found_full = 0
if @.@.fetch_status = 0 and @.found_full = 0
begin
set @.sqlstring = 'alter database ' + @.dbname + ' set RESTRICTED_USER with
rollback immediate'
exec (@.sqlstring)
set @.sqlstring = 'alter database ' + @.dbname + ' set MULTI_USER with
rollback immediate'
exec (@.sqlstring)
-- check file isnt zipped, if so decompress & restore
if charindex('.gz', @.restore_filename) > 0 or charindex('.zip',
@.restore_filename) > 0
begin
SELECT @.sqlstring = @.zippath + '\gzip.exe -d ' + @.backuppath +
@.restore_filename
EXEC @.error = master..xp_cmdshell @.sqlstring, NO_OUTPUT
set @.restore_filename = replace(@.restore_filename, '.gz', '')
set @.restore_filename = replace(@.restore_filename, '.zip', '')
end
--set @.sqlstring = 'alter database ' + @.dbname + ' set RESTRICTED_USER
with rollback immediate'
--exec (@.sqlstring)
set @.sqlstring = 'RESTORE DATABASE ' + @.dbname + ' ' +
'FROM DISK= ''' + @.backuppath + @.restore_filename + ''' ' +
'WITH ' + @.fullbackupmovecommand + ' , STANDBY = ''' + @.standbyfile + ''''
exec (@.sqlstring)
etc......

Logistics - Transaction Log Backup

I rent a dedicated server at a hosting site for a database-driven web
application. I have been doing daily backups of the SQL 2K database (Simple
Recovery method) and then use another service to ship that backup off
somewhere else in the world (can only schedule a backup once a day) in
addition to the daily system backup by the hosting company. Recently, the
server crashed and took with it my RAID drives as they were unreadable
somehow. The data was retrieved but I lost a day's worth of data.
So, I would like to NOT lose a day's worth of data again, and move to a Full
Recovery method with daily full backups with transaction log backups
periodically throughout the day. My trouble is that since I don't have a
dedicated tape machine, or access to a network drive (somewhere far away
from my server), and don't know of any FTP programs (to where?) that would
move those logs off my server, I'm wondering what others do. Just saving
those logs throughout the day won't do any good if the server crashes two
minutes before the backup.
Thanks for any tips on the logistics of backup.For smaller database I do backup locally, then have another job step (or all inside the stored
procedure) that uses the "DOS" COPY command to copy that files over to another machine. If that
isn't an option, I do the backup though an UNC directly to the other machine.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Don Miller" <nospam@.nospam.com> wrote in message news:OxjxSf3cGHA.4900@.TK2MSFTNGP02.phx.gbl...
>I rent a dedicated server at a hosting site for a database-driven web
> application. I have been doing daily backups of the SQL 2K database (Simple
> Recovery method) and then use another service to ship that backup off
> somewhere else in the world (can only schedule a backup once a day) in
> addition to the daily system backup by the hosting company. Recently, the
> server crashed and took with it my RAID drives as they were unreadable
> somehow. The data was retrieved but I lost a day's worth of data.
> So, I would like to NOT lose a day's worth of data again, and move to a Full
> Recovery method with daily full backups with transaction log backups
> periodically throughout the day. My trouble is that since I don't have a
> dedicated tape machine, or access to a network drive (somewhere far away
> from my server), and don't know of any FTP programs (to where?) that would
> move those logs off my server, I'm wondering what others do. Just saving
> those logs throughout the day won't do any good if the server crashes two
> minutes before the backup.
> Thanks for any tips on the logistics of backup.
>|||Just out of curiosity, have you checked with your hosting company about
doing the tape backup for you? Most provide this with your monthly fee
if it's their server.
At any rate, you can write a DTS package to move your backups via FTP
to wherever you like.|||Yes, I've talked to the hosting company (who does the entire system backups
to tape for a monthly fee) and this request (can I use their tape as a
device for backing up log files) seemed to puzzle them.
In the interim today, I found a service called LiveVault that does DB
backups of the "open" .mdf and .ldf files every 15 minutes without
transaction logs or any intervention with "standard" SQL 2K backup methods.
The problem is that this service costs as much as the server per month.
"PSPDBA" <williambr@.state.pa.us> wrote in message
news:1147200884.116152.217410@.i39g2000cwa.googlegroups.com...
> Just out of curiosity, have you checked with your hosting company about
> doing the tape backup for you? Most provide this with your monthly fee
> if it's their server.
> At any rate, you can write a DTS package to move your backups via FTP
> to wherever you like.
>|||You probably wouldn't want to use a tape as a backup device. You are
much better off (quicker) to backup to disk, then transfer to tape.
You can probably just give them the directories you want backed up and
the schedule.
It all comes down to what your downtime costs you - figure that out and
you'll know which avenue is best.

Logistics - Transaction Log Backup

I rent a dedicated server at a hosting site for a database-driven web
application. I have been doing daily backups of the SQL 2K database (Simple
Recovery method) and then use another service to ship that backup off
somewhere else in the world (can only schedule a backup once a day) in
addition to the daily system backup by the hosting company. Recently, the
server crashed and took with it my RAID drives as they were unreadable
somehow. The data was retrieved but I lost a day's worth of data.
So, I would like to NOT lose a day's worth of data again, and move to a Full
Recovery method with daily full backups with transaction log backups
periodically throughout the day. My trouble is that since I don't have a
dedicated tape machine, or access to a network drive (somewhere far away
from my server), and don't know of any FTP programs (to where?) that would
move those logs off my server, I'm wondering what others do. Just saving
those logs throughout the day won't do any good if the server crashes two
minutes before the backup.
Thanks for any tips on the logistics of backup.For smaller database I do backup locally, then have another job step (or all
inside the stored
procedure) that uses the "DOS" COPY command to copy that files over to anoth
er machine. If that
isn't an option, I do the backup though an UNC directly to the other machine
.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Don Miller" <nospam@.nospam.com> wrote in message news:OxjxSf3cGHA.4900@.TK2MSFTNGP02.phx.gbl
..
>I rent a dedicated server at a hosting site for a database-driven web
> application. I have been doing daily backups of the SQL 2K database (Simpl
e
> Recovery method) and then use another service to ship that backup off
> somewhere else in the world (can only schedule a backup once a day) in
> addition to the daily system backup by the hosting company. Recently, the
> server crashed and took with it my RAID drives as they were unreadable
> somehow. The data was retrieved but I lost a day's worth of data.
> So, I would like to NOT lose a day's worth of data again, and move to a Fu
ll
> Recovery method with daily full backups with transaction log backups
> periodically throughout the day. My trouble is that since I don't have a
> dedicated tape machine, or access to a network drive (somewhere far away
> from my server), and don't know of any FTP programs (to where?) that would
> move those logs off my server, I'm wondering what others do. Just saving
> those logs throughout the day won't do any good if the server crashes two
> minutes before the backup.
> Thanks for any tips on the logistics of backup.
>|||Just out of curiosity, have you checked with your hosting company about
doing the tape backup for you? Most provide this with your monthly fee
if it's their server.
At any rate, you can write a DTS package to move your backups via FTP
to wherever you like.|||Yes, I've talked to the hosting company (who does the entire system backups
to tape for a monthly fee) and this request (can I use their tape as a
device for backing up log files) seemed to puzzle them.
In the interim today, I found a service called LiveVault that does DB
backups of the "open" .mdf and .ldf files every 15 minutes without
transaction logs or any intervention with "standard" SQL 2K backup methods.
The problem is that this service costs as much as the server per month.
"PSPDBA" <williambr@.state.pa.us> wrote in message
news:1147200884.116152.217410@.i39g2000cwa.googlegroups.com...
> Just out of curiosity, have you checked with your hosting company about
> doing the tape backup for you? Most provide this with your monthly fee
> if it's their server.
> At any rate, you can write a DTS package to move your backups via FTP
> to wherever you like.
>|||You probably wouldn't want to use a tape as a backup device. You are
much better off (quicker) to backup to disk, then transfer to tape.
You can probably just give them the directories you want backed up and
the schedule.
It all comes down to what your downtime costs you - figure that out and
you'll know which avenue is best.

login names are deleted after restoring the backups

hi all
i have taken backup of a database 'XYZ' and restored it to a different
server with the same database name 'XYZ', it restored all the items/objects
successfully but the users of that database had blank loginnames in the
restored database. now it makes the objects of that user unaccessable
(without the login name the user cannot access its tables in the database).
i have also tried to make the users before database restoration but when the
database backup is restored it eliminates the user loginname
i'll be thankyou if anyone has the solution
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200508/1HI,
Tranfer all the logins from the mainserver to ur restored database from
dts.
or restore the master database backup
from
sufian|||You need to remap the user in the database to the logins on the other server
(assuming they exist). I tend to prefer to use sp_SidMap for this task which
can be found in the MapSids link in the following KB article
HOW TO: Resolve Permission Issues When You Move a Database Between Servers
That Are Running SQL Server
http://support.microsoft.com/Default.aspx?id=240872
--
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Daniyal khan via SQLMonster.com" <forum@.SQLMonster.com> wrote in message
news:526E5BAE50074@.SQLMonster.com...
> hi all
> i have taken backup of a database 'XYZ' and restored it to a different
> server with the same database name 'XYZ', it restored all the
> items/objects
> successfully but the users of that database had blank loginnames in the
> restored database. now it makes the objects of that user unaccessable
> (without the login name the user cannot access its tables in the
> database).
> i have also tried to make the users before database restoration but when
> the
> database backup is restored it eliminates the user loginname
> i'll be thankyou if anyone has the solution
>
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200508/1

login names are deleted after restoring the backups

hi all
i have taken backup of a database 'XYZ' and restored it to a different
server with the same database name 'XYZ', it restored all the items/objects
successfully but the users of that database had blank loginnames in the
restored database. now it makes the objects of that user unaccessable
(without the login name the user cannot access its tables in the database).
i have also tried to make the users before database restoration but when the
database backup is restored it eliminates the user loginname
i'll be thankyou if anyone has the solution
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums...erver/200508/1
HI,
Tranfer all the logins from the mainserver to ur restored database from
dts.
or restore the master database backup
from
sufian
|||You need to remap the user in the database to the logins on the other server
(assuming they exist). I tend to prefer to use sp_SidMap for this task which
can be found in the MapSids link in the following KB article
HOW TO: Resolve Permission Issues When You Move a Database Between Servers
That Are Running SQL Server
http://support.microsoft.com/Default.aspx?id=240872
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Daniyal khan via droptable.com" <forum@.droptable.com> wrote in message
news:526E5BAE50074@.droptable.com...
> hi all
> i have taken backup of a database 'XYZ' and restored it to a different
> server with the same database name 'XYZ', it restored all the
> items/objects
> successfully but the users of that database had blank loginnames in the
> restored database. now it makes the objects of that user unaccessable
> (without the login name the user cannot access its tables in the
> database).
> i have also tried to make the users before database restoration but when
> the
> database backup is restored it eliminates the user loginname
> i'll be thankyou if anyone has the solution
>
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums...erver/200508/1

login names are deleted after restoring the backups

hi all
i have taken backup of a database 'XYZ' and restored it to a different
server with the same database name 'XYZ', it restored all the items/objects
successfully but the users of that database had blank loginnames in the
restored database. now it makes the objects of that user unaccessable
(without the login name the user cannot access its tables in the database).
i have also tried to make the users before database restoration but when the
database backup is restored it eliminates the user loginname
i'll be thankyou if anyone has the solution
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200508/1HI,
Tranfer all the logins from the mainserver to ur restored database from
dts.
or restore the master database backup
from
sufian|||You need to remap the user in the database to the logins on the other server
(assuming they exist). I tend to prefer to use sp_SidMap for this task which
can be found in the MapSids link in the following KB article
HOW TO: Resolve Permission Issues When You Move a Database Between Servers
That Are Running SQL Server
http://support.microsoft.com/Default.aspx?id=240872
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Daniyal khan via droptable.com" <forum@.droptable.com> wrote in message
news:526E5BAE50074@.droptable.com...
> hi all
> i have taken backup of a database 'XYZ' and restored it to a different
> server with the same database name 'XYZ', it restored all the
> items/objects
> successfully but the users of that database had blank loginnames in the
> restored database. now it makes the objects of that user unaccessable
> (without the login name the user cannot access its tables in the
> database).
> i have also tried to make the users before database restoration but when
> the
> database backup is restored it eliminates the user loginname
> i'll be thankyou if anyone has the solution
>
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200508/1