Not a candidate for alternate buffer method: shared memory is not in use

[Mouhamadou]

Hi ,

I'm facing issues on all Database backup (Oracle , SQL). The job starts and hang on "begin writting" a long time before it fails and return the error code 6.

My plateforme is :

1 Master Server 

4 Media server 

2 DataDomain 

i Have tested the communication between masters , media and the client and it works. In attachement you can see the different logs such as the dbclient and the bptm and the bprd.

Thank you for your help

Regards

[Marianne]

Please show us all text in Job Details related to the logs?

[Mouhamadou]

Hello Marianne ,

Here is the job details :

29 janv. 2019 12:26:43 - Info nbjm (pid=9644) starting backup job (jobid=1008707) for client tnsvcour01.orange-sonatel.com, policy FICHIER_BASE_SQL_SRV1, schedule FULL

29 janv. 2019 12:26:43 - Info nbjm (pid=9644) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=1008707, request id:{4FF51C58-076E-410E-B0A4-E9E277E30F2B})

29 janv. 2019 12:26:43 - requesting resource STU_DD_DEDUP_MEDINA

29 janv. 2019 12:26:43 - requesting resource MESVNBUMASTER.orange-sonatel.com.NBU_CLIENT.MAXJOBS.tnsvcour01.orange-sonatel.com

29 janv. 2019 12:26:44 - granted resource  MESVNBUMASTER.orange-sonatel.com.NBU_CLIENT.MAXJOBS.tnsvcour01.orange-sonatel.com

29 janv. 2019 12:26:44 - granted resource  MediaID=@aaaaf;DiskVolume=StorageUnit1;DiskPool=DP_DD_DEDUP_MEDINA;Path=StorageUnit1;StorageServer=DD4500MED;MediaServer=MESVNBUMEDIA02.orange-sonatel.com

29 janv. 2019 12:26:44 - granted resource  STU_DD_DEDUP_MEDINA

29 janv. 2019 12:26:44 - estimated 0 kbytes needed

29 janv. 2019 12:26:44 - Info nbjm (pid=9644) started backup (backupid=tnsvcour01.orange-sonatel.com_1548764804) job for client tnsvcour01.orange-sonatel.com, policy FICHIER_BASE_SQL_SRV1, schedule FULL on storage unit STU_DD_DEDUP_MEDINA

29 janv. 2019 12:26:47 - started process bpbrm (pid=6048)

29 janv. 2019 12:26:48 - Info bpbrm (pid=6048) tnsvcour01.orange-sonatel.com is the host to backup data from

29 janv. 2019 12:26:48 - Info bpbrm (pid=6048) reading file list for client

29 janv. 2019 12:26:48 - connecting

29 janv. 2019 12:26:49 - Info bpbrm (pid=6048) listening for client connection

29 janv. 2019 12:26:50 - Info bpbrm (pid=6048) INF - Client read timeout = 10000

29 janv. 2019 12:26:50 - Info bpbrm (pid=6048) accepted connection from client

29 janv. 2019 12:26:50 - Info dbclient (pid=4036) Backup started

29 janv. 2019 12:26:50 - connected; connect time: 0:00:00

29 janv. 2019 12:26:50 - Info bptm (pid=4172) start

29 janv. 2019 12:26:55 - Info bptm (pid=4172) using 262144 data buffer size

29 janv. 2019 12:26:56 - Info bptm (pid=4172) setting receive network buffer to 1049600 bytes

29 janv. 2019 12:26:56 - Info bptm (pid=4172) using 512 data buffers

29 janv. 2019 12:26:59 - Info bptm (pid=4172) start backup

29 janv. 2019 12:27:00 - Info bptm (pid=4172) backup child process is pid 1748.4832

29 janv. 2019 12:27:00 - begin writing

29 janv. 2019 12:27:00 - Info bptm (pid=1748) start

29 janv. 2019 13:27:02 - Info dbclient (pid=4036) done. status: 6

29 janv. 2019 13:27:12 - Info dbclient (pid=4036) done. status: 6: the backup failed to back up the requested files

29 janv. 2019 13:27:12 - end writing; write time: 1:00:12

the backup failed to back up the requested files  (6)

[Marianne]

Please post one set of logs and job details for the SAME failing backup.

None of the timestamps or PIDs in the logs match the Job details. 

The timestamps in bprd and dbclient are different as well. 

Please include bpbrm on media server as well.

One more favour, please - upload files with .txt extentions? 
.log files cannot be opened on a mobile device.

We need to follow the entire process flow.
Backup seems to be initiated here (from dbclient log):

08:16:48.957 [3652.1288] <2> logconnections: BPRD CONNECT FROM 10.100.97.154.63464 TO 10.100.54.110.1556 fd = 612

But there is nothing in bprd that matches this.

[Mouhamadou]

here is the logs. please notice that the timeout was increased for a test  before we take it back to normal , but it seems like data doesn't move after "begin writting". 

[Marianne]

The latest job failed due to a timeout. 
So, there is nothing else to troubleshoot other than the timeout. 

According to bpbrm (and job details), the Client Read timeout on the media server is 300. 
bpbrm fails after 5 minutes:
09:54:43.795 [4100.5664] <2> bpbrm readline: bpbrm timeout after 300 seconds

dbclient reports :
serverResponse: initial client_read_timeout = <900>
dbclient fails 15 minutes later with: 
10:04:37.013 [3396.4868] <16> readCommFile: ERR - timed out after 900 seconds while reading from C:\Program Files\Veritas\NetBackup\Logs\user_ops\mssql\logs\0130119094911-3396-5996-000-000-prg

Could you please locate this progress log on the SQL client and post here (as .txt)?
C:\Program Files\Veritas\NetBackup\Logs\user_ops\mssql\logs\0130119094911-3396-5996-000-000-prg

Is this (900)  the Client Read Timeout on the master? 
Any reason for different timeouts on master and media server?

bptm log seems to be from a different media server. 
There is no record of this backup in the file that you uploaded.
Please upload correct bptm file? 

PS: 
Please only enable level 5 logging if you want to log a Support call with Veritas.
Level 3 normally provides sufficient info and produce 'manageable' size files.

[Marianne]

@Mouhamadou

I think I may have found something. Please have a look at this and please ignore the reference to NBU upgrade:

https://www.veritas.com/support/en_US/article.TECH58164

Read through the problem description - it matches your issue exactly. 

If I read what's causing the issue, I see the same thing on my laptop with new installation of NBU 8.0 client software (no upgrade). 
nblog.conf has this entry : 
Default.L10nLib=C:\Program Files\Veritas\NetBackup\bin\vxextwincat 
While the actual filename in C:\Program Files\Veritas\NetBackup\bin is vxextwincat_3.dll. 

Probably worth to try the 'Workaround'. 

If that does not fix the problem, please log a Support call with Veritas and mention that you are experiencing the exact same problem as described in this TN.