Overview

The information below shows how to find out when DXi logs should be escalated to the Sustaining Engineering group, what types of issues may occur, what information needs to be collected, and the escalation steps.

 

Note: Every service request escalation requires the capture of DXi logs. It's best to capture these logs immediately after failure, or as soon as possible thereafter.

 

---

When to Contact Sustaining Engineering

Before escalating an issue to Sustaining Engineering, make sure that you have completed these steps:

 

1. Review DXi messages logs, tsunami.log, LSI logs, 3ware output, etc., as needed.
2. Verify that DXi Best Practices have been applied.
3. Use available resources:
   • Quest (this search engine searches the next 4 items:
   • Bugzilla for related PTRs
   • CSweb for any related TSBs
   • Oracle SR history
   • KB articles
   • DXi Sustaining TWIKI pages:
     • http://dxwiki.quantum.com/mediawiki/index.php?title=DXiSustaining/Debugging_Tips_and_Tricks&redirect=no
     • Tips and Notes according to product. Examples:
       • http://dxwiki.quantum.com/dxwiki/DebuggingGalaxy
       • http://dxwiki.quantum.com/dxwiki/Eclipse:DebuggingEclipse
       • The Available Information section in the DXi Sustaining Web, “Misc” section: http://boris.adic.com/twiki/bin/view/DxiSustaining/WebHome
   • The ASPS Web site: http://denlaspsv1/asps/wordpress/
4. Consult peers, ask others in ASPS Team, and e-mail Service Engineering Specialist (SES).

It is acceptable practice to contact SES if your question will not take more than 10 minutes. For issues longer than 10 minutes, you will need to search for the information in some of the other sources described in this document, or work through the escalation process. Times could vary, depending on the customer’s temperature and management's input.

Rules of Thumb

Good rules of thumb about when a call to the next level are appropriate are as follows:

 

• Can the question with any needed context be explained/asked in a few short sentences?
• Does the question have a yes or no answer? If not, is the answer likely to be short?

Questions requiring long log listings or several paragraphs in an e-mail are tip offs that a formal escalation is probably the right way to go.

 

---

What Needs to be Sent to Sustaining

It's important to send the Sustaining team information found in the escalation form to the extent it can be determined.

1. Gather the appropriate data, according to the issue, and provide a detailed problem description, including the following:
   • Timestamps of events
   • OS versions
   • Backup application name and version
   • Switch, HBA, or NIC information
   • A description about whether or not the problem is reproducible
   • A description about what has been done to solve the problem
2. Gather additional details:
   • DXi Issues:
     • DXi logs from target and source
     • dbexport from target and source (DXi Advanced Reporting Tool)
     • Core files in /scratch/core 
     • blockpool_master.log (replication, deduplication, blockpool issues)
     • Blockpool quick report (replication, deduplication, blockpool issues)
     • LSI logs (array, performance, FC communication issues)
     • Kdump (Kernel Panic) /snfs/kdump
   • Ecosystem (connectivity, network, I/O performance issues):
     • Backup application error information and logs
     • OS information (UNIX, Windows), server logs
     • SAN/LAN configuration (diagram if possible)
       • Fabric, switch, and FC HBA information, speed, etc
       • Ethernet technology (Gigabit, 100BaseT, etc.), NIC information,
       • CIFS, NFS, Windows Active Directory, Workgroup

---

 What's Next?

DXi Log Reading Summary >