BACKUP VERIFY

Hi everyone,
While investigating why some of our SQL BUs were taking so long I have
realised that the person who set up the jobs initally has actually included 2
statements in the job step: a BACKUP one and a BACKUP VERIFY statement.
Now at the moment, and I am not sure if it is right, the verify statement is
taking longer to run than the initial backup.
I understand why you would want to use this statement straight after running
a back up but considering that it is taking so long, is it actually causing
more problem in our situation.
Before I consider disabling the statement I would like to get
recommendations on how, when, where and why you would use it? I am after best
practices and any known issues that may be related to the BACKUP VEDRIFY
statement.
Any info, suggestions, recommendations are welcomed regarding the subject.
Thanks in advance
Regards
BabeBACKUP VERIFY dos not guarantee that the backup file can be restored, though
it does give you a higher degree of confidence. In practice, I rarely, if not
never, use it. I certainly would not schedule it immediately after each
BACKUP statement for databases of any significant size.
Linchi
"Babe" wrote:
> Hi everyone,
> While investigating why some of our SQL BUs were taking so long I have
> realised that the person who set up the jobs initally has actually included 2
> statements in the job step: a BACKUP one and a BACKUP VERIFY statement.
> Now at the moment, and I am not sure if it is right, the verify statement is
> taking longer to run than the initial backup.
> I understand why you would want to use this statement straight after running
> a back up but considering that it is taking so long, is it actually causing
> more problem in our situation.
> Before I consider disabling the statement I would like to get
> recommendations on how, when, where and why you would use it? I am after best
> practices and any known issues that may be related to the BACKUP VEDRIFY
> statement.
> Any info, suggestions, recommendations are welcomed regarding the subject.
> Thanks in advance
> Regards
> Babe|||Please note, that usefullness of BACKUP VERIFY depends on version of MS SQL.
On MS SQL 2005 it checks checksums. On the previous versions it only checks
the internal structure of backup file.
Recuping, the only way to check your backup is restore. Doing BACKUP VERIFY
on the versions before MS SQL 2005 (specially in the cases other than tape
backup where media errors are more probable) is wasting of your time.
"Babe" wrote:
> Hi everyone,
> While investigating why some of our SQL BUs were taking so long I have
> realised that the person who set up the jobs initally has actually included 2
> statements in the job step: a BACKUP one and a BACKUP VERIFY statement.
> Now at the moment, and I am not sure if it is right, the verify statement is
> taking longer to run than the initial backup.
> I understand why you would want to use this statement straight after running
> a back up but considering that it is taking so long, is it actually causing
> more problem in our situation.
> Before I consider disabling the statement I would like to get
> recommendations on how, when, where and why you would use it? I am after best
> practices and any known issues that may be related to the BACKUP VEDRIFY
> statement.
> Any info, suggestions, recommendations are welcomed regarding the subject.
> Thanks in advance
> Regards
> Babe|||> On MS SQL 2005 it checks checksums.
... assuming the checksums are there, which they aren't by default. So to get a more reliable check,
the backup should be taken using the CHECKSUM option.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Dmitrij Siemieniako" <DmitrijSiemieniako@.discussions.microsoft.com> wrote in message
news:28A1B0A8-D219-46D4-B572-92D0E2FBEA66@.microsoft.com...
> Please note, that usefullness of BACKUP VERIFY depends on version of MS SQL.
> On MS SQL 2005 it checks checksums. On the previous versions it only checks
> the internal structure of backup file.
> Recuping, the only way to check your backup is restore. Doing BACKUP VERIFY
> on the versions before MS SQL 2005 (specially in the cases other than tape
> backup where media errors are more probable) is wasting of your time.
> "Babe" wrote:
>> Hi everyone,
>> While investigating why some of our SQL BUs were taking so long I have
>> realised that the person who set up the jobs initally has actually included 2
>> statements in the job step: a BACKUP one and a BACKUP VERIFY statement.
>> Now at the moment, and I am not sure if it is right, the verify statement is
>> taking longer to run than the initial backup.
>> I understand why you would want to use this statement straight after running
>> a back up but considering that it is taking so long, is it actually causing
>> more problem in our situation.
>> Before I consider disabling the statement I would like to get
>> recommendations on how, when, where and why you would use it? I am after best
>> practices and any known issues that may be related to the BACKUP VEDRIFY
>> statement.
>> Any info, suggestions, recommendations are welcomed regarding the subject.
>> Thanks in advance
>> Regards
>> Babe|||Hi everyone, thank you for the information/suggestions!
--
Babe
"Babe" wrote:
> Hi everyone,
> While investigating why some of our SQL BUs were taking so long I have
> realised that the person who set up the jobs initally has actually included 2
> statements in the job step: a BACKUP one and a BACKUP VERIFY statement.
> Now at the moment, and I am not sure if it is right, the verify statement is
> taking longer to run than the initial backup.
> I understand why you would want to use this statement straight after running
> a back up but considering that it is taking so long, is it actually causing
> more problem in our situation.
> Before I consider disabling the statement I would like to get
> recommendations on how, when, where and why you would use it? I am after best
> practices and any known issues that may be related to the BACKUP VEDRIFY
> statement.
> Any info, suggestions, recommendations are welcomed regarding the subject.
> Thanks in advance
> Regards
> Babe