Hi Tom,

Symptom looks similar to APAR: 
http://www-01.ibm.com/support/docview.wss?uid=swg1IC99847
but this APAR is fixed in 7.1.6.2

Therefore you really should give it a try to seperate the backup commands 
in small portions like:

tdpsqlc backup DB1,DB2,DB3,DB4,DB5 full....
tdpsqlc backup DB6,DB7,DB8,DB9,DB10 full....

and so on.

Your list of TDP clients is also correct. 7.1.6.X is the DP for SQL 
version to go in an environment with many different SQL Server editions 
and you do not want to have different DP clients. 

Best regards
----------------------------------------------------------------------------

Markus Stumpf
Service Operations Manager

IBM Certified Deployment Professional - Spectrum Protect V 8.1. 
Grandfathered
IBM Certified Deployment Professional Tivoli Storage Manager V6.3 
Grandfathered

Empalis Consulting GmbH
Wankelstrasse 14
70563 Stuttgart
t_    +49 711 46928 260
f_    +49 711 46928 239
m_ +49 (0) 172  5414567
mailto:markus.stu...@empalis.com

http://www.empalis.com

Geschäftsführer: Rainer Schilling, Peter Röder
Amtsgericht Stuttgart, HRB 738239

Konto: 0258228 bei Deutsche Bank AG Heilbronn BLZ 620 700 24 

Diese e-Mail einschließlich ihrer Anhänge ist vertraulich. Wir bitten, 
eine fehlgeleitete e-Mail
unverzüglich vollständig zu löschen und uns eine Nachricht zukommen zu 
lassen. Wir haben die
e-Mail beim Ausgang auf Viren geprüft; wir raten jedoch wegen der Gefahr 
auf den Übertragungswegen 
zu einer Eingangskontrolle. Eine Haftung für Virenbefall schließen wir 
aus.

This e-mail and any attachments are confidential. If you are not the 
intended recipient of this
e-mail, please immediately delete its contents and notify us. This e-mail 
was checked for virus 
contamination before being sent. Nevertheless, it is advisable to check 
for any contamination 
occurring during transmission. We cannot accept any liability for virus 
contamination.
 



Von:    Tom Alverson <tom.alver...@gmail.com>
An:     ADSM-L@VM.MARIST.EDU
Datum:  25.05.2017 23:28
Betreff:        Re: [ADSM-L] TSM TDP SQL backup crashes after first 
database
Gesendet von:   "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>



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 <aefim...@gmail.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.alver...@gmail.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 <aefim...@gmail.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.alver...@gmail.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 <aefim...@gmail.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.alver...@gmail.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.
> >>>>
> >>
>




Reply via email to