Re: [ADSM-L] TSM TDP SQL backup crashes after first database

Nothing very interesting ends up in that log.  Here is the tail end of it:

05/25/2017 17:20:46.180 [007140] [6972] : backupdb.cpp        (2748): DB
Object Name: 20170525172044\00001BE4
05/25/2017 17:20:46.180 [007140] [6972] : backupdb.cpp        (2751): Exit
CBackupDb::GetDbObjectName()
05/25/2017 17:20:46.180 [007140] [6972] : clcstatu.cpp        ( 558): Enter
CStatus::dbCommandStatus()
  statusInfo.type: 0x6
  command        : 0x3
05/25/2017 17:20:46.180 [007140] [6972] : clcstatu.cpp        (1884): Exit
CStatus::dbCommandStatus(), rc = 0
05/25/2017 17:20:46.180 [007140] [6972] : dsmapi.cpp          (2940): Enter
DDsmApi::writeLogMessage()
05/25/2017 17:20:46.180 [007140] [6972] : dsmapi.cpp          (2952):
logMessageInData.insertArray[0] = TDP MSSQL
05/25/2017 17:20:46.180 [007140] [6972] : dsmapi.cpp          (3661): Enter
DDsmApi::ddsmLogMessage()
05/25/2017 17:20:46.180 [007140] [6972] : baseapi.cpp         ( 187): Enter
DBaseApi::StartApiCall()
05/25/2017 17:20:46.180 [007140] [6972] : baseapi.cpp         ( 192): Exit
DBaseApi::StartApiCall()
05/25/2017 17:20:46.205 [007140] [6972] : baseapi.cpp         ( 205): Enter
DBaseApi::EndApiCall()
05/25/2017 17:20:46.205 [007140] [6972] : baseapi.cpp         ( 300): Enter
DBaseApi::GetApiName()
05/25/2017 17:20:46.205 [007140] [6972] : baseapi.cpp         ( 304): Exit
DBaseApi::GetApiName(), returning api name TSM
05/25/2017 17:20:46.205 [007140] [6972] : baseapi.cpp         ( 231): Exit
DBaseApi::EndApiCall(), elapsed milliseconds 24, total time 57 for TSM Apis
05/25/2017 17:20:46.205 [007140] [6972] : dsmapi.cpp          (3668): Exit
DDsmApi::ddsmLogMessage(), rc = 616
05/25/2017 17:20:46.205 [007140] [6972] : dsmapi.cpp          (2965): Exit
DDsmApi::writeLogMessage(), dsmLogMessage rc = 616
05/25/2017 17:20:46.205 [007140] [6972] : dsmapi.cpp          (2940): Enter
DDsmApi::writeLogMessage()
05/25/2017 17:20:46.205 [007140] [6972] : dsmapi.cpp          (2952):
logMessageInData.insertArray[0] = TDP MSSQL
05/25/2017 17:20:46.205 [007140] [6972] : dsmapi.cpp          (3661): Enter
DDsmApi::ddsmLogMessage()
05/25/2017 17:20:46.205 [007140] [6972] : baseapi.cpp         ( 187): Enter
DBaseApi::StartApiCall()
05/25/2017 17:20:46.205 [007140] [6972] : baseapi.cpp         ( 192): Exit
DBaseApi::StartApiCall()

On Thu, May 25, 2017 at 4:30 PM, Efim <aefim771 AT gmail DOT com> wrote:

> I would select a small first database and execute a trace.
> tdpsqlc backup db01,db02,db03 full /TRACEFILE=XX:\trace.txt
> /TRACEFLAG=SERVICE,API
> Efim
>
>
> > 25 мая 2017 г., в 22:30, Tom Alverson <tom.alverson AT GMAIL DOT COM>
> написал(а):
> >
> > We always use legacy.  I did try it as VSS but got an odd authentication
> > error?? Since we never use VSS I didn't know if that was important.
> There
> > are no errors in the windows event logs, just the successful backup
> event.
> > I did go into the SQL management console and did a backup from there to
> > .BAK files with no issues.  I don't think these are always on or anything
> > like that.
> >
> > On Thu, May 25, 2017 at 3:06 PM, Efim <aefim771 AT gmail DOT com> wrote:
> >
> >> The version is correct.
> >> Do you use legacy or VSS backup? If VSS: did you run the VSS diagnostics
> >> on all the disks where the databases are located (configuration wizard)
> ?
> >> What are the errors in the DP logs and windows events at the time of
> >> copying? Are these AlwaysOn databases?
> >> Efim
> >>
> >>> 25 мая 2017 г., в 21:45, Tom Alverson <tom.alverson AT GMAIL DOT COM>
> >> написал(а):
> >>>
> >>> The version number for sqlserver.exe is 10.50.6220.0 which indicates
> >> 2008R2
> >>> SP3.  My reading of the compatibility lists led me to create this table
> >>> (let me know if this is wrong) and 7.1.6.x should even go back as far
> as
> >>> SQL server 2008 (non-R2):
> >>>
> >>> TSM TDP Version SQL Version Support
> >>> 6.3.0 2005 2008 2008R2
> >>> 6.3.1 2005 2008 2008R2 2012
> >>> 6.4.0 2008 2008R2 2012
> >>> 6.4.1 2008 2008R2 2012
> >>> 7.1.0 2008 2008R2 2012
> >>> 7.1.1 2008 2008R2 2012 2014
> >>> 7.1.2 2008 2008R2 2012 2014
> >>> 7.1.3 2008 2008R2 2012 2014
> >>> 7.1.4 2008 2008R2 2012 2014
> >>> 7.1.6 2008 2008R2 2012 2014 2016
> >>>
> >>> On Thu, May 25, 2017 at 1:53 PM, Efim <aefim771 AT gmail DOT com> wrote:
> >>>
> >>>> Hi,
> >>>> Which service pack is installed on SQL?
> >>>> DP supports only 2008R2 SP2 and later.
> >>>> Efim
> >>>>
> >>>>
> >>>>> 25 мая 2017 г., в 20:35, Tom Alverson <tom.alverson AT GMAIL DOT COM>
> >>>> написал(а):
> >>>>>
> >>>>> I have an SQL 2008R2 database server with 32 databases on it.  My
> >> backup
> >>>>> job crashes like this after the first database is successfully backed
> >> up:
> >>>>>
> >>>>> Beginning full backup for database Application_Registry_Service_DB,
> 1
> >>>> of 32.
> >>>>> Full: 0   Read: 3232256  Written: 3232256  Rate: 2,452.60 Kb/Sec
> >>>>> Full: 0   Read: 3234560  Written: 3234560  Rate: 2,061.85 Kb/Sec
> >>>>> Database Object Name: 20170525132822\0000040C
> >>>>> Backup of Application_Registry_Service_DB completed successfully.
> >>>>>
> >>>>> It even exits with errorlevel 0, but does not continue on to the next
> >>>>> database, and never finishes up the summary log.
> >>>>>
> >>>>> If I exclude that database the same thing happens on the second
> >> database.
> >>>>> If I exclude the first two, it crashes on the third, etc etc.   If I
> >> try
> >>>>> these in the GUI, the GUI crashes at the end of the first backup.  I
> >> have
> >>>>> already updated to the latest clients I had around:
> >>>>> BACLIENT 7.1.6.4
> >>>>> TDP SQL    7.1.6.2
> >>>>>
> >>>>> Does anyone have any insight on what might be happening? The windows
> >>>> event
> >>>>> log just shows a successful backup of the first database and no
> errors.
> >>>>
> >>
>