Accelerate your resolution…

I’ve been doing a lot of work with the Remote Diagnostic Agent (RDA) lately testing the new up and coming RDA 8.0 engine with IdM RDA modules, and I thought it would be useful to highlight an important aspect of this much used diagnostic config and log snapshot tool.

When capturing RDA data to assist Oracle support in problem analysis, RDA works best when we capture a wide breadth of data early on in the SR lifecycle encompassing all platform data and integrated products.


One of the issues I often see is people don’t view RDA in the proper context.  Clearly RDA is geared to give you detailed log and config data on the particular product you see the issue on, the problem here is it’s easy to get fixated on capturing data only on that product.  The key to leveraging RDA’s ability to speed up the Time to Resolution (TTR) comes from capturing not just the problem product data but data on all pertinent aspects of the platform, particularly any integrated product.


When an SR begins its lifecycle with Oracle Support it is logged against a specific product so the SR goes to an engineer experienced in that product.  However it is often the case that a symptom exhibited in one product is actually caused by some other integrated product, but that’s hard to tell without some detailed analysis of the RDA data.  If we don’t have all the necessary data to hand it means more delays in TTR due to additional requests for information.  In addition, if the initial engineer finds the issue lies outside their product area, they will need to collaborate with another engineer who also needs to have their product data at hand so they can start to work quickly.   Not having all/enough data is made worse if an SR has to be worked 24/7 so it follows the Sun to the next time zone.  The new engineer in the next time zone may need more RDA data on the integrated products, and if this is outside the customer’s time zone they may not be on hand to provide the additional data which causes far greater delays.


When capturing RDA try not to second guess where the problem lies, capture everything that looks relevant and integrated to the product exhibiting the problem.  If half of that data never gets used it’s no big deal….but, if you capture that critical nugget of error data in some unexpected product area you could shave off days from your resolution time!

Make use of the RDA profiles rather than configuring one or two modules to be captured, and add on individual RDA modules to a profile for any integrated products that are not encompassed in the RDA profile you’ve chosen.

Conrad.

Comments:

RCA efforts often use pareto analysis and time series analysis to help facilitate root cause analysis; how does RDA help here ?

Posted by guest on June 30, 2013 at 09:20 PM MDT #

You're right, RDA won't help in an RCA for a couple of reasons -- First, by the time we do an RCA, the RDA has long since been deleted. And second, the RCA is normally a review of the body of the SR, relying instead on relevant snippets from an RDA having been posted there.
The RDA's strengths have more to do with troubleshooting the problem, collecting information that could help at the outset to quickly point to a solution without a lot of back and forth to collect it.
Irina

Posted by guest on July 31, 2013 at 08:39 AM MDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About


This is the official blog of the Proactive Support Team for Identity Management: OIM, OAM, OID, OVD, OUD, DSEE, etc. Find information about our activities, publications, product related information and more.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today