Wednesday, July 30, 2008

Additional platforms supported for Enterprise Manager 10gR4 agents

Windows x64, Linux x64 and Linux Itanium based Enterprise Manager Grid Control 10gR4 agents are now available. To get them, download the Mass Agent Deployment package from OTN.

http://www.oracle.com/technology/software/products/oem/index.html

Friday, July 18, 2008

New Application Management Pack for Siebel Customer Self Study Training Available

Application Management Pack for Siebel’s eStudy is now available. The self pace online course is a tutorial for deploying, configuring and using our Siebel pack. The course assumes familiarity of base EM capabilities taught in the 5 days instructor led Enterprise Manager Grid Control training course, and complements other training that covers EM features such as Service Level Management and Configuration Management in greater depth. You may access this training at the following URL.

http://ilearning.oracle.com/ilearn/en/learner/jsp/rco_details_find.jsp?srchfor=1&rcoid=534367447

Thursday, July 10, 2008

What can do I with this SARM data?

I woke up this morning finding a message in my inbox coming from an ITtoolbox subscriber asking about SARM. Wow, I thought, someone is trying to use my baby. So I replied the message over breakfast. The information may be interesting to others who want to know more about SARM, so I am re-posting it here.

>>>>>>>>>>>>>>>>>>>>

I was the original product manager for SARM. Let me provide some explainations.

Back in Siebel 6, it was easy to figure out performance problems, as Siebel client ran as a Win32 program on PC, and connected directly to the database. Each user connect via a separate database session, and all the business logic ran on the client PC.

Things got a bit more complicated with Siebel 7. With the web based interface, Siebel 7 enables organizations to be more agile, as they could revise their application more easily to reflect changing business processes without pushing the software out to thousands of users. However, the architecture also placed more demand on the mid-tier servers. In addition, a single transaction request (query, save, navigation, etc...) requiring going from web browser to web server, from web server to Siebel App Server, and from Siebel App Server to database server. Connection to database could be shared via database connection pooling. Tracing transaction from the user to the database in order to identify performance bottleneck root cause became very difficult, as it was very difficult to tell which user initiated what database request, and there was no way to figure out what the mid-tier was doing. In Siebel's own IT department, everytime a performance problem occured, the IT staff would summon a couple engineers from our product development organization to figure out the problem. This was very expensive in engineering productivity, and most customers did not have this option.

In Siebel 7.5, I asked our IT operations director what we could give his staff to make life easier. The answer was a way to see what goes on inside the Siebel app server environment. SARM was born as a result.

SARM is made up of three parts. The first is the instrumentation framework. The second is the collection of instrumentation. The third is the tool for analyzing the data. SARM instrumentations are strategically placed in various parts of the Siebel software stack.

When a transaction request enters the Siebel server layer, the first timer goes off. As the request makes it way down the stack (think of it as a call graph), additional timers go off. These instrumentation points capture timing information, CPU/memory utilization, and contextual information about that instrumentation point. Data for each instrumentation point makes up a single SARM entry.

Each SARM entry includes the identification of the instrumentation point (AreaDesc). For example, the workflow engine would be one of those instrumentation points. For workflow, the application string field also stores the name of the workflow, so that you can tell not only the workflow engine is invoked, but also the particular workflow that is being run, and the amount of time spent running that workflow. User id, business component name, view name, applet names are also stored in the entries of the respective areas.

Let's say you have a transaction request that ran for 15 seconds. You want to find out the breakdown of the time spent. Using the area description and the text string, you can find out how much time is spent at each Siebel layer, and find out the exact workflow, business service or script that is causing the problem. You would know who initiated the transaction request since the user id is recorded, and which part of the application (view and applet name) the request came from.

It took a couple releases to get SARM fully done. 7.5 was the first release. Naturally, with any version 1.0 technology, there were some short comings, and there were not too many instrumentation points to capture data. In 7.7, the technology became much more mature, with better optimization to minimize overhead, and more instumentation coverage after we took a companywide effort to ask every single development team to instrument their code with SARM. 7.8 was an application functional release so SARM in 7.7 pretty much was the same in 7.7. We made further improvements in 8.0 to give administrators more ways to fine tune SARM data collection.

In addition, one thing that had been missing in SARM was a good graphical tool to analyze all the rich information. The command line tool, which was intended to convert the binary SARM data to CSV so that people could import it into spreadsheet, just didn't cut it. The reason why we didn't come up with a graphical tool initially was resource constraint. We needed to focus our energy on making sure we could collect good SARM data first and did it in an efficient way. Otherwise, the best analytical tool in the world wouldn't help.

The lack of good graphical tool also changed in the Siebel 8 timeframe. One thing that is cool about being part of Oracle is that Oracle has a lot more people. We actually have a whole division of people focusing on building management tools. So after we became part of Oracle, we shipped a graphical tool (Siebel Diagnostic Tool) as part of Application Management Pack for Siebel. In fact, we have done more to the management tooling of Siebel in the past year than the 10+ years when Siebel was an independent company. The tool is now fully integrated with Application Management Pack for Siebel, which runs as part of Oracle Enterprise Manager 10gR4.

I wrote about SARM on my blog in May, and will probably write about it more in the coming months, so check it out for more discussion. I will also be presenting a session on SARM at this year's OpenWorld in September so stop by if you are going to attend the conference. http://appmanagementblog.blogspot.com/2008/05/demystifying-siebel-application.html

Visit this site if you want to learn more about Application Management Pack for Siebel. http://www.oracle.com/technology/products/oem/prod_focus/app_mgmt.html