Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-2252040.1
Update Date:2017-09-28
Keywords:

Solution Type  Problem Resolution Sure

Solution  2252040.1 :   SL8500/SL3000/SL500 - Any Move of Tape With RecvrMove or Any Eject of a Tape From SLC, Without Running a DIVA sync DB, Will Heavily Impact on DIVA Tape Pool Database  


Related Items
  • Sun StorageTek SL3000 Modular Library System
  •  
Related Categories
  • PLA-Support>Sun Systems>TAPE>Tape Hardware>SN-TP: OEM Drive and Library
  •  




In this Document
Symptoms
Changes
Cause
Solution
References


Created from <SR 3-14573202741>

Applies to:

Sun StorageTek SL3000 Modular Library System - Version All Versions to All Versions [Release All Releases]
Information in this document applies to any platform.

Symptoms

Customer environment:

Library Type: SL3000 RoHS Level: 2006
Version: FRS_4.31 (7.33.00)

Backup application : DIVA version 6.5

Customer has encountered one issue with the robot which has been replaced. Afterwards a drive failed as the load mechanism seemed to be defective. Customer tested the drive load function using RecvrMove from SLC by following the steps from the below document:

How to Move tape from a cell via SLC (SL-Console) using RecvrMove to the CAP and re-enter the cartridge(s). (Doc ID 2093578.1)

Drive failed to be loaded with tape ARC503 but the tape was not returned to its original slot. Tape was ejected from the library and the drive was replaced.

After drive replacement, the backup application DIVA was explicitly requested to load the tape ARC503 to a drive as some important files might have been requested in the backup process for restore job. However, the fact that the tape have been ejected from the library heavily impacted in DIVA operations as DIVA ACTOR tried to mount the tape to each drive and downed all of them as it failed to find tape ARC503.

SL3000 Robot manager SCSI Logs reported that the mount request was sent at slot level, and the corresponding slot (where DIVA knows that the ARC503 tape is stored) is empty (because that tape has been used for a testing, then ejected from the cap, then reinserted, outside the DIVA system control (via SL console)

29/03/17;19:55:21;0;MediaChanger; MediaChanger : MoveMedium -> Source = 2068 Destination = 1000;
29/03/17;19:55:21;0;MediaChanger; MediaChanger : MoveMedium -> Step 1;
29/03/17;19:55:21;0;MediaChanger; MediaChanger : MoveMedium -> Step 2;
29/03/17;19:55:21;0;MediaChanger; MediaChanger : Command buffer is Size = 12 Content = a5 00 00 00 08 14 03 e8 00 00 00 00 ;
29/03/17;19:55:21;0;SCSIDevice;p_Command = Size = 12 Content = a5 00 00 00 08 14 03 e8 00 00 00 00 ;
29/03/17;19:55:21;0;SCSIDevice;p_Response = Size = 0 Content = ;
29/03/17;19:55:21;0;SCSIDevice;Illegal request : source element empty.,SenseKey=0x05, ACS=0x3b, ACSQ=0x0e;;
29/03/17;19:55:22;0;SCSIDevice;p_Command = Size = 12 Content = a5 00 00 00 08 14 03 e8 00 00 00 00 ;
29/03/17;19:55:22;0;SCSIDevice;p_Response = Size = 0 Content = ;
29/03/17;19:55:22;0;SCSIDevice;Illegal request : source element empty.,SenseKey=0x05, ACS=0x3b, ACSQ=0x0e;
29/03/17;19:55:22;0;SCSIDevice;p_Command = Size = 12 Content = a5 00 00 00 08 14 03 e8 00 00 00 00 ;
29/03/17;19:55:22;0;SCSIDevice;p_Response = Size = 0 Content = ;
29/03/17;19:55:22;0;SCSIDevice;Illegal request : source element empty.,SenseKey=0x05, ACS=0x3b, ACSQ=0x0e;
29/03/17;19:55:22;0;MediaChanger; MediaChanger : MoveMedium -> SCSIDeviceException: Illegal request : source element empty.,SenseKey=0x05, ACS=0x3b, ACSQ=0x0e, code 990 () [.\SCSIDevice.cpp:88];

This suggests that Diva tried to move the tape from source slot 2068 (which was the last known location for the tape ARC503) and the library returned the SCSI Sense Code SenseKey=0x05, ACS=0x3b, ACSQ=0x0e, which corresponds to the message: 'source element empty'.

Changes

 None

Cause

Any move of tape with RecvrMove or any eject of a tape from SLC, without running a sync DB on DIVA, will heavily impact on DIVA tape pool database

Please be aware of the fact that DIVA does not have the ability to auto-synchronize with the library tape database. After any operations performed in SLC it is highly recommended to advise customers to follow the steps described in the below document:

How To Synchronize DB So That DIVA Is Aware Of Library Changes (Doc ID 2179099.1)

Solution

Restart of the DIVA ACTOR Manager solved the sync issue . However , please be aware that any kind of operations performed from SLC and involving tape movements will heavily impact on backup production as DIVA won't be aware of the changes . The only solution would be to Synchronize DB So That DIVA Is Aware Of Library Changes.

References

<NOTE:1377490.1> - SL500/SL3000/SL8500 - Procedure for Collecting One Button Log Snapshot From Library
<NOTE:1382859.1> - SL8500/SL3000 - How to Troubleshoot "servo mech grip" Events
<NOTE:1384809.1> - SL8500/SL3000 - How to Troubleshoot "Servo Mech Reach" Events

Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback