Presenting again!! OAUG Connection Point - AppsTech 2016

Hi everybody!!  Have you been wondering what I have been up to lately?  Well, the cat is out of the bag now with the presenter list for the OAUG Connection Point - AppsTech 2016 conference now online and my brand new presentation "R12: Reducing the data footprint of Oracle E-Business Suite" is listed!!  This is a great honor as this was by invite only, and this project is the one I alluded too earlier in the year in my Happy New Years post which I have been doing work on for quite some time but now I feel confident that I have enough material for a new presentation!  Do not miss this opportunity to learn from a lot of experts in application technology by registering today!!

How to tell if AWR data takes up too much space in SYSAUX tablespace

Are you looking for ways to reduce space in your environment?  Check out My Oracle Support note 287679.1 for the article "How to Address Issues Where AWR Data Uses Significant Space in the SYSAUX Tablespace" so you can validate your settings and find out if there are ways to eliminate extra data including orphaned records!

Workflow is filling up FND_LOG_MESSAGES

This is a problem I have posted about previously, but since I just presented some of this information during my session at COLLABORATE, I think the new post on MOS "Workflow Messages Are Filling Up FND_LOG_MESSAGES" via article ID 2006609.1 comes along at exactly the right time for EBS Support personnel!  Find out what else you need to be looking for, besides the profile options to get logging turned off for this table!

R12: FND_LOG_MESSAGES

Along the lines of my presentation, and published article, I bring you new details of another vector you need to verify to not bloat your database.  Looking into the space consumption of our database post R12 upgrade, the DBAs found that the table FND_LOG_MESSAGES was taking up 13% of our space in PROD so they found My Oracle Support document 735138.1 which details how to purge this information.  Why is this related to R12 you ask?  Based on some of the data analysis scripts in my article, I substituted in FND_LOG_MESSAGES and found that prior to R12 our monthly total in this table was just under 3.5 million rows added back in 2010.  Yet, the largest volume of data added to this table was in October when we went to R12 of over 320 million rows.  Okay, sure the system churn and processing might be excessive when installed so let's look at the next highest month that's been completed; in November we more than 233 million rows added to FND_LOG_MESSAGES, which is an increase over 67 times between our previous high and the following month after R12 was installed!

I have a few more nuggets of information to share with you about this situation, so stay tuned the next few days if you're interested by this!

EDIT: I realized I forgot to add in the links to my other articles last night!

Weekend Reading: Database performance and data types

File this one away in the "needed to sit down to review it" type of follow up post, but the article by Pythian's Edwin Sarmiento is no less effective or topical because of that.  As I've peeled back the onion of what makes Oracle databases and applications tick, the lessons suggested here will help you when designing solutions and also are good reminders for how you can either tune something wrong or look for a potential problem just waiting to strike.  Wouldn't we all like to avoid database bloat?  Who is not looking for faster ways to access our data?

Oracle Advanced Compression highlights

Did you know that Oracle Database version 11g brings with it a host of new features, one of which is Oracle Advanced Compression?  If you didn't, you may want to browse this article which has a testimonial on how this feature allowed a customer to reduce their footprint by 50 percent.  Or, you can skip to the next article to see how another client reduced their database resources by 400 percent and you can find tools that let you self-assess your savings with and without compression.

Data (historical and backups)

I had found this post a little while ago on cleaning up historical data, but I wanted to save blogging about it until I had something real to say about it.  This is that time as it has become very apparent that another one of our Main Tenants should be something to do with data, maybe Data Consumption or Data Usage but SOMETHING because data is just piling up in our systems every day.  Audit data, user data, this data, and that data and how much is being purged, how much can be purged, who has a strategy for keeping track of all of this and where does that fit in with a corporate strategy?

Skip several years later, and the database had grown to be huge for that time. Retrievals were taking longer and longer, and talking to some of the sysadmins late at night around the coffee machine, I learned that the backup was getting too large to even back it up within a week. The application was starting to hit pretty much a ‘brick wall’; it started to fall further and further behind, and something really needed to be done.

Does this sound familiar?  How big is your system?  Has it hit 1 TB?  Are you approaching 5, 10, 50, 100, or more TB of space for your footprint?  How do you approach your backup system?  Do the people that manage your backups tell you when you're having a problem, or do you have to figure it out yourself?  Questions like this are going through my head as I re-read that link because lately in the morning I'm seeing something like this in our new event monitoring alert:

  Waits                                                           Wait Time        Server

 

  Backup: MML create a backup piece           79291.40622    X1

  Backup: sbtbackup                                        3937.101761   X2                  

  Backup: sbtbackup                                      17308.812339   X3

 

This sure seems like our systems are suddenly "wasting" a lot of cycles per hour on backups, especially when these events are from backups that run into our morning several hours and sometimes even into the afternoon.  So begins the investigation!