RE: 10g on unix. Partitions... Tablespaces... and best practices
Date: Tue, 13 Jan 2009 10:39:58 -0500
Anyone who tells you that >50 tablespaces is too many ought to have reasons to back up the claim. To me 50 sounds like an arbitrary number, and I think that you are using partitioning and tablespaces exactly the way they are meant to be used.
I know of production databases with tablespace counts in the thousands.
Prime Services Databases Americas
One Madison Avenue
New York, NY 10010
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of April Wells Sent: Tuesday, January 13, 2009 10:32 AM To: oracle-l_at_freelists.org
Subject: 10g on unix. Partitions... Tablespaces... and best practices
Okay, I need to know if there exists a best practices document that I can't find anywhere yet.
I need to find a way to justify (or change my way of thinking).
I have a data warehouse
I have heavily partitioned data (partition by month) with each partition in its own tablespace
I can make old data read only and speed up backups
I can maintain at the tablespace level
I can compres at the tablespace level
I have "way too many" tablespaces (this has been suggested more than once and has been posed as a problem with my thinking and my judgement) and there is supposed to be some document somewhere that says no database needs more than 50 tablespaces (odd though about that E-business suite thing for years).
Does anyone have any pointers to good partitioning best practices document so I can re-educate myself or something.
SR Oracle DBA
This electronic transmission and any attached documents or other writings are confidential and are for the sole use of the intended recipient(s) identified above. This message may contain information that is privileged, confidential or otherwise protected from disclosure under applicable law. If the receiver of this information is not the intended recipient, or the employee, or agent responsible for delivering the information to the intended recipient, you are hereby notified that any use, reading, dissemination, distribution, copying or storage of this information is strictly prohibited. If you have received this information in error, please notify the sender by return email and delete the electronic transmission, including all attachments from your system.
Please access the attached hyperlink for an important electronic communications disclaimer:
Received on Tue Jan 13 2009 - 09:39:58 CST