Too many 196 errors, but the windows has just opened

[andrich2016]

The schedulles that start 02h or 03h AM are stopping with 196 erros.

The same schedulles start after one hour and finihish ok.

Any reason?

Thanks

[andrich2016]

Thats the dbclieent log.

03:00:24.431 [16693] <8> xbsa_GetEnv: WRN - NBBSA_SCHEDULE not found in environment block
03:00:24.432 [16693] <2> int_LogSystemInfo: INF - Veritas NetBackup for Oracle - Release 7.7.3 (2016051915) System name: SunOS Node name: svsistel Release: 5.11 Version: 11.2 Machine: sun4v User name: oracle Client Host: svsistel
03:00:24.432 [16693] <2> int_GetMMInfo: INF - Initialized Signal
03:00:24.432 [16693] <2> int_GetMMInfo: INF - support for Proxy Copy enabled
03:00:24.790 [16695] <8> xbsa_GetEnv: WRN - NBBSA_SCHEDULE not found in environment block
03:00:24.790 [16695] <2> int_LogSystemInfo: INF - Veritas NetBackup for Oracle - Release 7.7.3 (2016051915) System name: SunOS Node name: svsistel Release: 5.11 Version: 11.2 Machine: sun4v User name: oracle Client Host: svsistel
03:00:24.790 [16695] <2> int_GetMMInfo: INF - Initialized Signal
03:00:24.790 [16695] <2> int_GetMMInfo: INF - support for Proxy Copy enabled
03:00:25.142 [16697] <8> xbsa_GetEnv: WRN - NBBSA_SCHEDULE not found in environment block
03:00:25.142 [16697] <2> int_LogSystemInfo: INF - Veritas NetBackup for Oracle - Release 7.7.3 (2016051915) System name: SunOS Node name: svsistel Release: 5.11 Version: 11.2 Machine: sun4v User name: oracle Client Host: svsistel
03:00:25.142 [16697] <2> int_GetMMInfo: INF - Initialized Signal
03:00:25.142 [16697] <2> int_GetMMInfo: INF - support for Proxy Copy enabled
03:00:25.490 [16699] <8> xbsa_GetEnv: WRN - NBBSA_SCHEDULE not found in environment block
03:00:25.490 [16699] <2> int_LogSystemInfo: INF - Veritas NetBackup for Oracle - Release 7.7.3 (2016051915) System name: SunOS Node name: svsistel Release: 5.11 Version: 11.2 Machine: sun4v User name: oracle Client Host: svsistel
03:00:25.490 [16699] <2> int_GetMMInfo: INF - Initialized Signal
03:00:25.490 [16699] <2> int_GetMMInfo: INF - support for Proxy Copy enabled

[andrich2016]

Thats the /usr/openv/netbackup/bin/admincmd/bppllist svsistel-oracle -U

Schedule: Differential-Inc
Type: Differential Incremental Backup
Frequency: every 1 day
Excluded Dates----------
No specific exclude dates entered
No exclude days of week entered
PFI Recovery: 0
Maximum MPX: 1
Retention Level: 0 (1 week)
Number Copies: 1
Fail on Error: 0
Residence: (specific storage unit not required)
Volume Pool: (same as policy volume pool)
Server Group: (same as specified for policy)
Residence is Storage Lifecycle Policy: 0
Daily Windows:
Monday 02:00:00 --> Monday 05:00:00
Tuesday 02:00:00 --> Tuesday 05:00:00
Wednesday 02:00:00 --> Wednesday 05:00:00
Thursday 02:00:00 --> Thursday 05:00:00
Friday 02:00:00 --> Friday 05:00:00
Saturday 02:00:00 --> Saturday 05:00:00

[andrich2016]

Two weeks ago wh change to Daylight saving time (DST) or summer time.

Thats the dates of media/master server and the client:

Media/master: # date
Wed Oct 26 08:54:54 BRST 2016

Client:date
quarta-feira, 26 de outubro de 2016 08h55min09s BRST

[Sandeepkumar]

Reduce the frequency of daily backups to hours,instead of 1 day and check.Refer below link to schedule frequency based backups.

If you initiate the backup manually is it happening successfully.?

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

[andrich2016]

Schedulles changed.

Lets wait until tomorrow.

Tx

[Lowell_Palecek]

The problem began with the switch to summer hours (DST), correct? Did the DST rules change recently for the country? What is the OS of the master server? If Windows, is it up-to-date with any DST patches from Microsoft?

[andrich2016]

The BRST (Brazilian SummerTime) began in October 15 and since this day the 196 error has occurred.

The master/media OS is SuSE 12 and the change to summer time was ok.

I´ve changed the schedulles to 1 hour instead one day for testing and the begin of the schedulle shows the same 196 error.

[Lowell_Palecek · Accepted solution]

We had a case in Turkey last spring. What the two countries have in common is that they set their clocks forward at midnight. (By comparison, the U.S. sets clocks forward at 1 a.m.

Here's a TechNote. The solution given is for Windows, which is what the Turkish customer had.

http://www.veritas.com/docs/000108027

 I'm a Windows guy; I don't know how to do the equivalent in Linux. However, in the troubleshooting for the Turks, it was suggested to remove the weekday of the time change from the schedule window. In their case, it was to remove Fridays. The point was to avoid having the policy execution manager (nbpem) avoid trying any calculations involving 12:00 am, Friday, April 1, 2016, which didn't exist. There's a bug in what happens next, which we're working on fixing.

In your case, you can try temporarily removing Sundays from your scheduling windows. This is to avoid a calculation that, looking forward for the next window after the last good scheduled backup, lands on Sunday, October 16, and hits our bug. I project, without proof, that once you get past the problem you can resume your Sunday schedules.

[andrich2016 · Accepted solution]

Hello Everybody

The solution was increase one hour for the schedulles who shows 196 erros.

[Lowell_Palecek]

This solution suggests that your client and servers don't agree on what time it is - dbclient was starting the backup when it thought the backup window opened, at which time the server was closing the backup window. You extended the window and it worked. Could that be the case?