Accelerate your resolution…
By ConradHope on May 31, 2013
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.