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@VM.MARIST.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@VM.MARIST.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 >