Very Computer

I currently run Seagate Backup Exec on a server which also runs
SQLServerv6.5 - I am not using the agent available to backup a running db
because we have no real use for it as the backups which run at night are
not going to interrupt any processes on SQL (in other words, we don't use
the db overnight - it is idle). I would, however, like to be able to
shutdown the SQL server before the b/u and start it up automatically after
the b/u has completed (Seagate allows for functions to be run before and
after b/u's) just to be sure that all info in the db has been backed up. Am
I correct in assuming that the "SHUTDOWN" command is all I need to run
before the b/u and the "sqlservr.exe" command is all I need to run after
the backup in order to be sure that all data is backed up successfully? Do
I need any other parameters behind the commands or is that sufficient to
shutdown all relevant services?

Thanks in advance.

--

Your best bet is to either dump(backup) the database base to disk, this is
only effective if you have enough disk.  The second solution would be to
dump(backup) the database directly to tape.  See the Administrator's
Companion, pg. 110, Managing Dump Devices.

Ryan Trout

Joel,

 Use the NET STOP MSSQLSERVER and NET START MSSQLSERVER commands
before/after the backup.

 Neil Pike MVP/MCSE
 Protech Computing Ltd

DO NOT!!! I repeat DO NOT attempt to backup SQL Server by shutting it down
and then backing up the disk devices. Although it "should" work ... I nearly
lost a job a few yrs ago by counting on it ... It was Sybase on NetWare, but
I've learned my lesson after SQL Server couldn't load the production
database after I restored the disk device backup.

Seagate sells a module for BackupExec to dump SQL Server databases. Either
get that or schedule a diskdump.

Jim-

Jim,

 Whilst I agree that it isn't ideal, I have used this method MANY times
in the past, and have restored with it as well.  It is perfectly safe
as long as you backup ALL the files and don't suffer a hardware/tape
problem - which would*you up whatever method you used.

 Neil Pike MVP/MCSE
 Protech Computing Ltd

Is this true ONLY if the device has NOT been extended ?

IF they have been extended, the device is fragmented (more than one
"fragment").
As I understand, if the device is fragmented, on a db restore, the
fragments have to be created and in the same order.  This was a
major problem for me when I first got into SQLserver, as I could
find little/no info about it.

I've opted for safe...when I had to extend the device and db,
I backed up the db, dropped the db and device, added drives,
created a new device and db of the increased size.  This kept
the device in a single piece.

....gary

--
Gary Nakayama
SAP BASIS/FI/CO

Does this include databases where the log and the data files are seperate?
My DB is not fragmented, but I have found when I restore, I have spurious
errors...My Log size is a little different each time, but I didn't think
that would matter...

Ben

I'm NOT a SQLserver "guru"...

But as I "understand" (which may be wrong) the fragments need to be
created in the same order and size that the fragments were created.  
My old servers (no longer w/co) had the log and data in separate
devices/files.  

There is a SP to run that will tell you what the fragments are.
In one of those servers I had to extend both the log and data devices,
and when I ran the SP it showed the fragments in the order I created
them.
Now ask me what that SP is, I need to go look thru my books...sorry.

I've spent a lot of money for books specifically to keep my *from
getting burned.  But there is precious specific info about this issue.
Hence my conservative route of a single fragment.  But I was fortunate
in being able to bring down the server to rebuild the db w/a single
fragment rather than having to extend the device.

I'm from the "old school"

   if it's a critical/production system,
   be VERY careful/conservative...your *is on the line...

? When I restore, I use an ISQL script to drop the db and device, then
to create the device and db then load the db.  I only had 1 bad restore
where I had to redo the restore, but (fingers crossed) but I never had
"spurious" errors.  What specific errors did you get ?

Whenever I get ANYTHING "strange" I run a full DBCC job against the 3
db;
master, msdb, "application-db".
IF there is a problem, I have a SQLserver consultant that I would call
for HELP.

....gary