-
ORA-00059: maximum number of DB_FILES exceeded
Hi guys,
We have reached to the limit of data files in our production DB and currently we cannot add data files.
Today we have a maintenance window and I want to increase the parameter DB_FILE and boune the DB.
Following some details:
DB version : 10.2.0.4
OS version: Sun Sparc Solaris 5.10 64 bit
DB_FILE=10000
Code:
PROD> ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 65000
vmemory(kbytes) unlimited
I wanted to consult with you how to configure now the parameter DB_FILE?
Increasing to 15,000? maybe more?
Thanks in advance
-
only you know how many files you will need, set it whatever you think you need
-
Actually , you're right
Thanks!!
-
Also you may want to consider increasing the size of the files instead of adding more.
"The person who says it cannot be done should not interrupt the person doing it." --Chinese Proverb
-
Yes, I've already configured DBFs size of tablespaces which contain large amount of data files.
So, I hope increasing from 10,000 to 15,000 will give me peace for long time...
Thanks
-
Originally Posted by nir_s
So, I hope increasing from 10,000 to 15,000 will give me peace for long time...
Just out of curiosity - do you really have in excess of 10,000 datafiles on your system? How big is that database?
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
-
-
While 43TB is a large database by any standard, you might benefit from looking through all of your table spaces and checking if you are using good storage methods. I.e. that you don't have 5 or 10 data files attached to a table space when 1 or 2 will do. That you don't have excessively large blocks sizes in table spaces where you have a lot of smaller tables, etc. The larger the database grows the more room there is for pruning. IMHO, small bites of 5-10 table spaces at a time would make more sense than larger changes.
-
Thanks for your recommendations!
We try to do our best to maintain such a huge DB , including storage configuration.
-
Originally Posted by nir_s
43tb!
Nice! that's a big f*&^% thing.
I'm sure you guys are having a lot of fun - on the database world "size matters"
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|