Hi Steve,

Interesting...
Our opinion is that the SQL Server should not allow a differential backup
to
be run on a database that has never had a full backup run on it.
The Microsoft documentation clearly states that when restoring a
differential backup,
you must first restore the full backup.
The problem with your "a" solution below is that DP/SQL cannot make
assumptions about
who took the full backup. If DP/SQL prevents the differential backup from
occurring
but the SQL Server allows it, we will surely get an APAR on that because
some
customers may be using a different technique for their full backups.
The general rule is that we try not to "outsmart" the SQL Server.

My suggestion is to open an official problem with IBM, and have the IBM
Service
person work directly with Microsoft to find out why the SQL Server is
allowing
this to happen in the first place. As an example, the Exchange Server will
not even
allow you to take a DIFFERENTIAL backup until a FULL backup has been
performed.
It errors out.

Until this is resolved, I suggest that you have your SQL Server DBAs
perform
a manual full backup right after they create a database.

Thanks,

Del

----------------------------------------------------

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 09/03/2009
06:41:50 AM:

> [image removed]
>
> Re: TDP-SQL behavior for diff backup of new databases
>
> Schaub, Steve
>
> to:
>
> ADSM-L
>
> 09/03/2009 06:44 AM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Please respond to "ADSM: Dist Stor Manager"
>
> Hi Del,
>
> Here is the log from the diff restore.  By creating a database in
> the middle of the week (and we only run a full on the weekends),
> there is no full backup to go along with the diff.  What I expected
> to happen the first time TDP tried a diff backup on a newly created
> database was either:
> a) TDP recognizes there is no full, and the diff becomes a full
> backup for the first run (preferred action)
> b) TDP fails the backup (at least I know there is a problem)
> It looks like neither happened.  So it appears that I could have a
> potential gap in coverage of up to a week for new databases?
>
> 09/01/2009 13:45:33 Restore of SQLBackupTest failed.
> 09/01/2009 13:45:33 An exception occurred while executing a
> Transact-SQL statement or batch.
> 09/01/2009 13:45:33 The database "SQLBackupTest" does not exist.
> RESTORE can only create a database when restoring either a full
> backup or a file backup of the primary file.
>
> Thanks,
> -steve
>