Showing posts with label Data Usage. Show all posts
Showing posts with label Data Usage. Show all posts
Monday, June 6, 2016
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!!
Monday, May 4, 2015
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!
Sunday, January 19, 2014
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?
Saturday, August 10, 2013
OVC - Reclaiming space
In running our Gather Schema for ALL schemas some interesting results popped up, one of which was the error message of “ORA-00900: invalid SQL statement” for a few objects. Researching what the items were by just running a select on the tables (OVCX_FINP_HLD_INVALIDS_0_0 and OVCX_FINP_HLD_PROFILES_0_0) I found that the items in question were actually tables in our system which were columns of HTML code which made up webpages when put together!!
Research on My Oracle Support finds this article "OVC Diagnostic Readme and Available Parameters" [ID 252733.1] which explains that these tables are artifacts of an older version of the Oracle Diagnostics, deprecated in lieu of the current Oracle Diagnostics bundle, and the tables were generated from the ovc.zip file which is still provided by Oracle via MOS Notes 297613.1 and 398834.1. While we only have a few of these objects in our system, reclaiming the space by dropping the tables won't be a whole lot for us by percentage, every byte is crucial and multiplied by every environment adds up to what your total storage budget is. Maybe you don't have any of these objects in your system laying around, but are you sure of it? Might be worth your time to go looking, don't you think?
Research on My Oracle Support finds this article "OVC Diagnostic Readme and Available Parameters" [ID 252733.1] which explains that these tables are artifacts of an older version of the Oracle Diagnostics, deprecated in lieu of the current Oracle Diagnostics bundle, and the tables were generated from the ovc.zip file which is still provided by Oracle via MOS Notes 297613.1 and 398834.1. While we only have a few of these objects in our system, reclaiming the space by dropping the tables won't be a whole lot for us by percentage, every byte is crucial and multiplied by every environment adds up to what your total storage budget is. Maybe you don't have any of these objects in your system laying around, but are you sure of it? Might be worth your time to go looking, don't you think?
Wednesday, October 31, 2012
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:
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!
Subscribe to:
Posts (Atom)