| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: System Tablespace
On Thu, 15 Jan 1998 16:00:28 GMT, "S Metro" <smetro_at_nospam.world.std.com> wrote:
>An application was just installed on our database that requires all users to
>have the SYSTEM tablespace as their default and temporary tablespaces.
>Apparently, their application cannot point users to other tablespaces.
This doesn't sound reasonable. Why should an aplication even bother with tablespaces? It should deal only with users schemas and their objects, not with underlying tablespaces. What does aplication even know about temporary segments and their tablespace???!!! Why should aplication care about users default tablespace???!!! Does this application also require all the rollback segments to be stored in system tablespace? Does this aplication also dictate the names of the datafiles conforming tablespaces? Extremely strange application ....
>I've heard this might be bad, but wanted to know why.
It is bad in many ways...
For the start, it is bad from purely aesthetic reasons - it's like you have a file system with only a root directory and everything stored in that directory.
It's bad for performance reasons - you will definitely suffer from tablespace fragmentation and I/O contention.
It's bad for managability - you can not take system tablespace offline (for whatever reason) or you can not make it read only, for example.
It's bad for backup and recovery - in many circumstances handling the system tablespace differ from other tablespaces when performing backup/recovery.
There are surlely many more reason why there shouldn't be any objects in SYSTEM tablespace except from those, owned by SYS.
>Any input would be greatly appreciated.
>
>Thanks,
>
>Scott
Regards,
Jurij Modic Republic of Slovenia jurij.modic_at_mf.sigov.mail.si Ministry of Finance ============================================================The above opinions are mine and do not represent any official standpoints of my employer Received on Thu Jan 15 1998 - 00:00:00 CST
 |
 |