- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: oracle10g create many large dump files
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
тАО02-18-2009 10:58 PM
тАО02-18-2009 10:58 PM
oracle10g create many large dump files
my problem is my database is create many large dump files in the directory cdump
I don't know what the trouble in my database?
thanx
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-20-2009 02:41 AM
тАО02-20-2009 02:41 AM
Re: oracle10g create many large dump files
BACKGROUND_DUMP_DEST, USER_DUMP_DEST, and CORE_DUMP_DEST initialization
parameters, respectively. Any user trace files are stored in UDUMP. Any
trace files made by background processes are stored in BDUMP. Any core
dump trace files are stored in CDUMP. You need these files to diagnose
problems with your database
It depends for how many days you need these files to be maintained for. I would delete files older than 30 days by having a cron job like :
find
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-20-2009 05:15 AM
тАО02-20-2009 05:15 AM
Re: oracle10g create many large dump files
>> I don't know what the trouble in my database?
Look at the time of the dump files.
Now open up (read) the Alert.log file in /bdump.
Try reading the dump and/or .TRC file (/udump)
You'll probably find a corresponding entry with an indication of the problem. POssibly aome mumbo-jumbo about memory or communications, but perhaps it triggers a correction or workaround thought.
Perhaps there is an 'ORA-600' indication ("something went badly wrong" :-).
Search METALINK for matches on errors number/text + platform.
Make sure you are up-to-date.
Don't spend too much time on it though, escalate to Oracle Support pretty quickly as it is not supposed to dump, no matter what.
That is, if for example memory is mis configured, it should just tell you, not dump.
Good luck!
Hein van den Heuvel.
HvdH Performance Consulting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-28-2009 05:42 AM
тАО02-28-2009 05:42 AM
Re: oracle10g create many large dump files
it is not clear, if you want to get rid of the dumpfiles or the error causing them.
If the later, you should give us some extract from these dumpfiles otherwise it would be just guessing.
You can use max_dumpfile_size in init.ora to limit their size.
Volker
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-23-2009 11:45 PM
тАО09-23-2009 11:45 PM