%BACKUP-I-BTCROUT messages during disk-to-disk backup

[Rene Heeres]

When doing a disk-to-disk backup I get informational messages several times, these messages are:
%BACKUP-I-BTCROUT, routine Write error detected, output Status, Call RESTORE_ERROR
%BACKUP-I-VALUE_TRACE_D, Decimal trace value 420

HELP/MESSAGE does not give a clue. Can anybody help? What is happening?

[Art Wiens]

Perhaps this explanation from "The Wizard" describes your situation:

http://h71000.www7.hp.com/wizard/wiz_9053.html

HTH,
Art

[Art Wiens]

It's not your exact error message, but it may be a general indication pointing to ODS-5.

[David B Sneddon]

Rene,

The messages are informational and looking at the
source listings tends to indicate that the
BTCROUT messages are trace or debug type output
that should probably not appear and may well just
have been left in due to a conditional build of
that version of BACKUP.
The 420 equates to
%SYSTEM-F-MEDOFL, medium is offline.
At what point in the backups do the messages appear?

Regards
Dave

[Rene Heeres]

The disk I made the backup of is an ODS-2 disk. The disk has Oracle (v. 8.1.7.4) databasefiles on it.

The point at which the messages appeared was somewhere during the backup (about halfway):
.
%BACKUP-S-CREATED, created $1$DGA337:[ORACLE.DB_MSW]MSW_AXAPTA_03.DBS;1
%BACKUP-S-CREATED, created $1$DGA337:[ORACLE.DB_MSW]MSW_AXAPTA_IND_03.DBS;1
%BACKUP-I-BTCROUT, routine Write error detected, output Status, Call RESTORE_ERROR
%BACKUP-I-VALUE_TRACE_D, Decimal trace value 420
%BACKUP-S-CREATED, created $1$DGA337:[ORACLE.DB_MSW]MSW_BHAIC1_1.DBS;1
%BACKUP-S-CREATED, created $1$DGA337:[ORACLE.DB_MSW]MSW_BHAIC1_2.DBS;1
%BACKUP-I-BTCROUT, routine Write error detected, output Status, Call RESTORE_ERROR
%BACKUP-I-VALUE_TRACE_D, Decimal trace value 420
%BACKUP-S-CREATED, created $1$DGA337:[ORACLE.DB_MSW]MSW_BHAIC1_7.DBS;1
.

The backup completed succesfully. At the moment we have the disk mounted and started the database on it and it seems to be working fine. I still wonder what happened.
Could there be a problem with the filestructure, I used ANALYZE/DISK and DFU VERIFY and they both reported no errors?

[David B Sneddon]

Since the disks involved are DGA devices is it
possible that the connection is being temporarily
lost? ... which would result in the MEDOFL status
being returned.
Can you monitor the state of the disks during
the backup to see if they are briefly going into
mount verify?
You should see this if you have another session
with REPLY/ENABLE.

Dave

[Rene Heeres]

Before the disk-to-disk was started we did restart the HSG80-controllerpair on which this disk is defined. There was at least half an hour between the restart of the controllers and the start of the disk-to-disk backup.

Could this restart, although it happened half an hour earlier, have anything to do with the messages that I got? Before starting the backup a SYSMAN io SCSI/Auto was performed to configure the disk and to verify the paths.

What are the chances that the copied data is in someway corrupted? Should I worry about that? The Oracle database on it (just used for querying) started without any problem.

[David B Sneddon]

I am not familiar with the HSG80. Since the backup
does not report any "errors" I would assume that
the backup is OK. I don't think the HSG80 reboot
would cause a problem unless it was done during
the backup, which it wasn't. The best thing to
do would be to have another session active with
REPLY/ENABLE or check the operator log to see if
any of the disks go into mount verify for a short
time.

Dave

[Martin P.J. Zinser]

Hi Renee,

how about the error counter on the target disk,
did this increase maybe? How about the ports on your FC switch, are these all clear?

Greetings, Martin

[Rene Heeres]

There are no errors on the target disk. I did see a path switch on the target disk ($1$dga337:) and also on the source disk ($1$dga760:) did go offline (Mount verify) twice for a very short while (0,2s).

Could this be the cause of the messages?
Does backup have a problem with a disk going into Mount Verify?

[David B Sneddon · Accepted solution]

Rene,

I suspect that the switching and going offline
are the source of the MEDOFL informational
messages. The purpose of mount verify is to
allow for the possibility of a transient state
to repair itself and have things come back to
normal. If the disk were to disappear totally
then backup would fail and report the appropriate
error. Since the backup is not reporting these
things as *errors* but as *informational* I would
not worry about it.

Dave

[Martin P.J. Zinser]

Hi Renee,

while I would not worry about the result of this particular backup, I would still check the ports on the FC switch. We did have cases of both GBICs and Fibre cables slowly dying that did manifest as path switches on the OS level.

Greetings, Martin

[Rene Heeres]

David, Martin,

Thank you for your responses, I now have a good idea what these messages mean and why they probably appeared during this particular backup.

I will monitor this HSG80-pair's ports on errors. We did restart this HSG80-pair because we had problems with it (we do not restart controllers just for fun ;-( ). Some systems had problems with the connection to port 1 of the top-controller, while other systems did not have any problem with it.
Restarting the controllers did not help, when we rebooted the systems as a final solution the problems were solved.

I logged a call for this problem. What I know sofar is that I looks like that the particular port is being overloaded with I/O's. This can be caused by servers that have a high I/O bandwidth (f.i. a GS1280 system).

[Duncan Morris]

What type of host adapter do you have?
If it is a KGPSA-EA, then the following might apply....

Required Firmware Update for FCA2384 (DS-KGPSA-EA)


customer advisory OI040319_CW01 revision 0
released March 2004 last updated 09 July 2004

description


PERFORMANCE ISSUE REGARDING POSSIBLE DATA CORRUPTION OR HARD APPLICATION ERRORS

While evaluating multiple configurations of Alpha Server systems in a stress-testing lab environment, HP has observed that excessive Fibre Channel abort sequences occurring while heavy sequential writes are in process could possibly lead to hard application errors or data corruption. The affected systems included only Alpha Servers equipped with FCA2384 model Host Bus Adapters (HBA) running OpenVMS or Tru64 UNIX. HP has released a firmware upgrade to address this issue and strongly advises the immediate upgrade of the HBA firmware to this version.

[Rene Heeres]

Hi Duncan,

We use the following adapters:
- KGPSA-CA (LP8000) - on the older systems
- KGPSA-** (LP9000) - on our GS1280 system
- KGPSA-** (LP9802) - on a DS25 system

I'm not sure if one the last two adapters is the KGPSA-EA. Could you tell me that?

Regards,

Rene

[Uwe Zessin]

DS-KGPSA-DA is LP9002
DS-KGPSA-EA is LP9802

Please note that the reverse is not always true, as the FCA2404 is based on the Emulex LP9802, too, but is for Windows 2003 (Itanium).

[Rene Heeres]

Duncan, Uwe,

Fortunately we have already updated the Firmware of these adapters to v. 1.00x8

Thanks anyway for pointing me at this advisory....

[Uwe Zessin]

There is now firmware version '1.81a5' for this adapter:

http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?locale=en_US〈=English+%28US%29&pnameOID=341798&prodSeriesId=341796&prodTypeId=12169&basePartNum=COL4356&locBasepartNum=co-21706-1&os=OpenVMS+7&tech=Firmware++Storage+Fibre+Channel

[Rene Heeres]

Uwe,

I also received this information today in the HP email notifications.
Unfortunately there is no accompanying README to tell me why I should upgrade my firmware.
We normally only upgrade the HBA firmware together with the firmware of the Alpaserver it is installed in.

Do you have any clue why I should update the Firmware of this HBA?

[Uwe Zessin]

No, sorry. But I gave feedback through the web page that I like to see this information. I was a bit disappointed that we got just a firmware file, but if others give similar feedback to HP this might change.