Tablespace size [message #683632] |
Tue, 09 February 2021 02:05 |
JackBauer
Messages: 24 Registered: February 2021
|
Junior Member |
|
|
Hello,
Do you usually keep your tablespaces below a given size?
What I mean is that we have some tablespaces that are 5 or 6 Teras in size.
What would you do to avoid this?
Thanks
|
|
|
Re: Tablespace size [message #683634 is a reply to message #683632] |
Tue, 09 February 2021 02:22 |
John Watson
Messages: 8963 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Welcome to the forum.
Please read the OraFAQ Forum Guide and How to use [code] tags and make your code easier to read.
I see no problem with a tablespace being of any size: it has be as big as it needs to be. Some DBAs (or SAs) don't like to have files over some size, but nowadays I always use bigfile tablespaces and have not had any problems. In their early days there were bugs when they grew to over 300GB or so, but that was years ago. The filesize limits for smallfile tablespaces are really annoying.
Going back a few decades I remember having to balance IO across numerous 2GB discs, striping tablespaces across zillions of little files. Thank heavens all that is history.
|
|
|
Re: Tablespace size [message #683635 is a reply to message #683632] |
Tue, 09 February 2021 02:34 |
|
Michel Cadot
Messages: 68731 Registered: March 2007 Location: Saint-Maur, France, https...
|
Senior Member Account Moderator |
|
|
The problem with very big size is with backup and recovery.
For instance, if you backup on tape, you should limit the size of files to the size of tape (minus some overhead for management). Having files spread over several tapes is really painful.
If you lose a file then you have to restore and recover it, the bigger it is the longer it will last.
This is the DBA point of view.
[Updated on: Tue, 09 February 2021 02:37] Report message to a moderator
|
|
|
Re: Tablespace size [message #683636 is a reply to message #683635] |
Tue, 09 February 2021 02:52 |
JackBauer
Messages: 24 Registered: February 2021
|
Junior Member |
|
|
That's exactly the point, backup and recovery.
The files are 131G max in size.
We just do RMAN backups and sometimes they require recovering a table or a couple of tables, so we have to recover the whole tablespace.
So we have to recover really huge tablespaces, and I don't know how to avoid this.
Thanks
|
|
|
Re: Tablespace size [message #683637 is a reply to message #683636] |
Tue, 09 February 2021 03:34 |
John Watson
Messages: 8963 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Quote:We just do RMAN backups and sometimes they require recovering a table or a couple of tables, so we have to recover the whole tablespace. I don't understand this. What do you mean by "recovering a table"? Surely that would be export/import. Or do you mean the RMAN recover table facility introduced in 12c? Which is in fact export/import anyway.
Surely you are not regularly getting file corruptions that mean you have to restore from backup.
|
|
|
Re: Tablespace size [message #683638 is a reply to message #683637] |
Tue, 09 February 2021 04:36 |
JackBauer
Messages: 24 Registered: February 2021
|
Junior Member |
|
|
If the dev team or someone has made a mistake and they ask us to recover a table with the data it had X days before. So we have to do the RMAN recovery.
The new RMAN recover table, also requires recovery for the whole tablespace where the table is located.
|
|
|
|
Re: Tablespace size [message #683644 is a reply to message #683643] |
Tue, 09 February 2021 10:17 |
JackBauer
Messages: 24 Registered: February 2021
|
Junior Member |
|
|
Yes, I suppose any DBA working with big volumes should create many data and index tablespaces for a given schema for administration purposes.
|
|
|
|
Re: Tablespace size [message #683646 is a reply to message #683645] |
Tue, 09 February 2021 11:39 |
|
Michel Cadot
Messages: 68731 Registered: March 2007 Location: Saint-Maur, France, https...
|
Senior Member Account Moderator |
|
|
Quote:General principle: EBS is as big and complicated as it gets
Maybe this also means you should not follow what they do.
(Why they want to rebuild indexes on transaction tables? How separating indexes from tables simplify recovery?)
As Ed suggested and I concur, the only thing to take into account to choose what tablespaces should be (number and size) is maintainability and mainly backup and restore.
If you can buy the Partition option and partition your objects then performances may also come into play.
[Updated on: Tue, 09 February 2021 11:39] Report message to a moderator
|
|
|