This blog post was originally released on Pythian blog

Concurrent processing is one of the key elements of any e-Business Suite system. It provides scheduling and queueing functionality for background jobs and it’s used by most of the applications modules. As many things depend on concurrent processing it’s important to make sure the configuration is tuned for your requirements and hardware specification.

This is the first article in a series about performance of concurrent processing. We’ll take a closer look at the internals of concurrent managers, the settings that affect their performance and the ways of diagnosing performance and configuration issues. Today we’ll start with an overview of the internal workflow of a concurrent manager process. Enjoy the reading.

This blog post was originally released on Pythian blog

As we all know proper use of bind variables in SQL statements is a must to make transaction processing applications scalable. So how do we find the queries that don’t use bind variables and have to be parsed each time they are executed? There is number of ways, but this article is all about the most effective way I know. If you have a better one - let me know please!

This blog post was originally released on Pythian blog

One of the hot topics at the UKOUG 2011 Technology and E-Business Suite Conference last December was the upcoming release of Oracle e-Business Suite R12.2. The new release will bring us lots of new features, usability improvements and new versions of technology stack components (Oracle Database 11g R2 and Oracle Fusion Middleware 11g R1 as the application server), but the most important and impressive new feature of course will be online patching. Online patching is supposed to change the game completely. All owners of E-Business Suite environments know that patching requires downtime. Although it can be reduced with various techniques (e.g. staged APPL_TOP), some downtime is still required to apply a number of changes. Online patching will not eliminate downtime completely, but will reduce it significantly by using “Edition Based Redefinition” (EBR) at the database level and using a secondary applications file system for online patching. In fact, all patching activity will be an online operation; downtime will be required only to switch from one version to another.

This blog post was originally released on Pythian blog

Another December has started and you know what it means right? It’s the Christmas time? NO! It’s time for UKOUG Technology and e-Business Suite 2011 conference! There are not many things that can make a passionate Apps DBA more excited than that. UKOUG Tech & eBS conferences are the only ones in Europe that have such a rich content for Application DBAs and this year it will not be different.

For me, the UKOUG Conference 2011 is going to be a very special one. I have some really good reasons for that: For the 1st time I’m representing Pythian at an international conference, I’m proud of that, but it also adds some additional pressure on my shoulders. It’s the 5th time I’m presenting at UKOUG conference (a little anniversary for me). And, I’m meeting few of my colleagues in person, which is really important as I’m working remotely from home and therefore miss seeing people and this is a good chance for me to catch up a bit on that.

How did I get here? Even though there are many eBS sessions during these conferences I think there’s not enough content specifically for Apps DBAs, there are a lot of presentation usually surrounding upgrading 11i to R12, R12 to Fusion Apps, etc., there’s always some presentations on how to integrate eBS with this and that, there’s almost always some presentations on how to configure something and presentations about what’s on the roadmap for us. In my opinion there are not enough presentations for Apps DBAs that would give you something that would be useful every day, something you can use when you go back to work after the conference. Therefore I thought I needed to improve the situation and submitted a presentation “Concurrent Processing Performance Analysis for Apps DBAs” and fortunately enough it got accepted.

If you are an apps DBA, please come and see the presentation on Wednesday, December 7th in Hall 10B at 14:25. I’ll give you the tools and knowledge to analyze the concurrent processing performance on your own. You will know how to find answers for questions like these after the presentation:

• Are there any periods of time when the pending times of the concurrent requests are longer than expected?
• Which concurrent programs are affected the most by increased pending times
• How to find out which requests exactly were pending to be executed by the manager?
• What was the root cause the request was pending (incompatibility with other requests or all of the managers were occupied)
• Which were the conflicting requests?
• Which managers could have run the requests?
• Which requests were processed on these concurrent managers at that time?
• What was the utilization level of particular concurrent managers?
• Are there too many, too few concurrent processes configured?

I hope to see you on Wednesday if you interested!

This blog post was originally released on Pythian blog

“Hello World!” I guess that’s the most appropriate way to start my 1st blog post under pythian.com domain. I’m going to start slow, but hopefully will pick up speed and have at least couple of posts each month to share with you. I’ve been blogging at http://appsdbalife.wordpress.com/ until now and I haven’t decided yet what the future will be for my previous blog, I wouldn’t like it to become some kind of a zombie page that’s been long dead but still wandering around the internet world.

Enough intros, let’s get to business! I hope this blog post doesn’t get lost in the huge amount of posts related to OOW 2011.

A few days ago I was asked to estimate how much space needed to be added to the ASM diskgroup to handle the database growth for one year without additional need of adding disks. Obviously, to estimate the disk space that needed to be added I had to know what the DB size will be in one year from now. It looked like an easy task as I knew we were recording the size of the database every day.