- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Saving Oracle trace file's question.
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2004 02:08 AM
тАО01-09-2004 02:08 AM
HP-UX 11.0 Oracle 8.1.7.3 MC/SG OVO 6.14
On our installation of Oracle in the directory
$ORACLE_HOME/admin/openview/udump/* there are
currently 1927 files (ora_xxxxx_openview.trc).
These files take up 1.7GB of space so far.
Average file size is 963KB.
Should we just keep only a few days worth of files or should we archive them all just in case? I want to free up disk space.
10 points to any good answer.
TIA, Gino
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2004 02:14 AM
тАО01-09-2004 02:14 AM
SolutionI think you're the best one to answer that question. Have you ever referred to them? Have you had to go back more than a few days? Would fetching them off a backup tape be reasonable if the need arises. If you're answers were no, no and yes, then I would definitely remove all but the most recent, probably via a nightly cron job.
Pete
Pete
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2004 07:18 AM
тАО01-09-2004 07:18 AM
Re: Saving Oracle trace file's question.
1927 files is quite a bit.
May be it would be better not just to get rid of them by delete, but read them, analyze the error that causes their creation and get rid of this error.
May be they do not show up any more if you patch to 8.1.7.4 (which is an easy action).
Regards
Volker
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2004 07:48 AM
тАО01-09-2004 07:48 AM
Re: Saving Oracle trace file's question.
not all traces are due to errors. Have a look at them and if they do not contain vital information, keep a couple of days and mv the rest to the digital nirvana. You also might want to check the level of tracing.
greetings,
Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2004 02:02 PM
тАО01-09-2004 02:02 PM
Re: Saving Oracle trace file's question.
Going by the SID, I'm guessing this is your OVO/NNM system. (and oh, duh, I should read :) It seems less critical. But I have to admit I'm a packrat. I tend to throw stuff like this onto tape and hang onto it for a while (deleting all but the latest originals). Tape is cheap. :)
Mic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2004 03:14 PM
тАО01-09-2004 03:14 PM
Re: Saving Oracle trace file's question.
I agree with Volker.
Read your alert
You may later compress or delete them all.
regards
Yogeeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-10-2004 11:52 PM
тАО01-10-2004 11:52 PM
Re: Saving Oracle trace file's question.
Apart from whatever has been said:
1. Background trace files are used to log errors that have been encountered by a background process, such as SMON, PMON, DBWn and other background processes.
2. These files exists only when an error requires writing to the trace files.
3. One should use these files to diagnose and troubleshoot problems.
Check the cause for the recent creation of trace files. Older ones definitely can be deleted.
sks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-11-2004 02:58 AM
тАО01-11-2004 02:58 AM
Re: Saving Oracle trace file's question.
If you are going to ignore errors, or may know that hundreds of them where caused by a poor database setting (like low shared pool :-) and that this situtation has since been cleared, then a bulk delete is appropriate. As long as you have some just tification.
Now, couldn't those trc file not also be actual sql traces? maybe someone/something on your system enabled sql tracing! CHeck the Oracle docs (or google) for the various ways to set and influence trace.
Some hints:
initXXX.ora (event 10046)
sqlnet.ora (... sql_trace=true..."
sqlplus glogin ... alter session set
(oradebug) event 10046 trace name context forever, level...
Cheers,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-11-2004 04:38 PM
тАО01-11-2004 04:38 PM
Re: Saving Oracle trace file's question.
As the name suggest udump, they are Background trace files only whose location is set by the parameter background_dump_dest.
Whereas User trace files (used for SQL tuning) will be in a directory like cdump and set by the parameter user_dump_dest. The size of these files can be controlled by max_dump_file_size.
sks