View Full Version : SYSTEM Tablespace is FULL
HARI OM
09-05-2003, 02:05 PM
I am using Oracle 9.2.0.1 on IBM AIX 5.1L
My following Tablespaces are 99% full....is it normal...? do I need to
increase manually or is ti done automatically:
---------------------------------------------------------
TABLESPACE SIZE USED %USED
---------------------------------------------------------
SYSTEM 400MB 394MB 98
EXAMPLE 138MB 137MB 99
XDB 38MB 37MB 99
---------------------------------------------------------
Do you think increasing the above Tablespace will increase the speed
also?
Any related informaiton is appreciated.
(Apologize for my ignorance)
THANKS!
Ron Reidy
09-05-2003, 07:00 PM
Hmmm... you most likely have things in SYSTEM that don't belong there.
You need to move them to a different TS.
What do you mean "increase the speed"? What is slow? Why is it slow?
What waits are you experiencing?
Hari Om wrote: I am using Oracle 9.2.0.1 on IBM AIX 5.1L My following Tablespaces are 99% full....is it normal...? do I need to increase manually or is ti done automatically: --------------------------------------------------------- TABLESPACE SIZE USED %USED --------------------------------------------------------- SYSTEM 400MB 394MB 98 EXAMPLE 138MB 137MB 99 XDB 38MB 37MB 99 --------------------------------------------------------- Do you think increasing the above Tablespace will increase the speed also? Any related informaiton is appreciated. (Apologize for my ignorance) THANKS!
--
Ron Reidy
Oracle DBA
Burt Peltier
09-05-2003, 11:50 PM
You provided insufficient information . You can look in the catalog at
dba_data_files (I think) to see if the files for these tablespaces
grow/extend automatically.
I don't see how you can connect "speed" with "size" ?
Your system tablespace seems unusually large and this could be from several
things including (at least in 8i and older):
1) Putting non-system objects(that's tables and indexes mainly) into the
system tablespace. Not good.
2) Some app that duplicates its unusually large data model. Not good.
3) A LOT of Plsql . Ok.
4) You have auditing turned on and are logging into the default location
which is the system tablespace. Not good.
I haven't done much with 9i yet, so the 4 reasons above might not be correct
for 9i.
--
"Hari Om" <hari_om@hotmail.com> wrote in message
news:d1d5ebe4.0309051405.56aca3e5@posting.google.com... I am using Oracle 9.2.0.1 on IBM AIX 5.1L My following Tablespaces are 99% full....is it normal...? do I need to increase manually or is ti done automatically: --------------------------------------------------------- TABLESPACE SIZE USED %USED --------------------------------------------------------- SYSTEM 400MB 394MB 98 EXAMPLE 138MB 137MB 99 XDB 38MB 37MB 99 --------------------------------------------------------- Do you think increasing the above Tablespace will increase the speed also? Any related informaiton is appreciated. (Apologize for my ignorance) THANKS!
If auditing is turned on, then it is possible that your
SYS.AUD$
table is growing and since this is in the SYSTEM tablespace it could be
responsible for it's size.
"Hari Om" <hari_om@hotmail.com> wrote in message
news:d1d5ebe4.0309051405.56aca3e5@posting.google.com...
| I am using Oracle 9.2.0.1 on IBM AIX 5.1L
|
| My following Tablespaces are 99% full....is it normal...? do I need to
| increase manually or is ti done automatically:
| ---------------------------------------------------------
| TABLESPACE SIZE USED %USED
| ---------------------------------------------------------
| SYSTEM 400MB 394MB 98
| EXAMPLE 138MB 137MB 99
| XDB 38MB 37MB 99
| ---------------------------------------------------------
|
| Do you think increasing the above Tablespace will increase the speed
| also?
|
| Any related informaiton is appreciated.
|
| (Apologize for my ignorance)
| THANKS!
Brian Peasland
09-08-2003, 07:10 AM
While I agree with all of the other posts that non-Data Dictionary items
should not be in SYSTEM, and that if auditing is being done that
SYS.AUD$ should be moved to a different tablespace, I feel that saying
that SYSTEM is too large is doing a slight injustice to the OP. We have
no idea what that database is being used for, what applications are
running against it, and what objects are stored in the database.
It is highly possible for SYSTEM to be 500MB and for it to be that way
on purpose. I have two rather large instances (1TB and 5TB) with 40,000+
objects that each have SYSTEM over 500MB. In those cases, it is a large
number of triggers and stored procs that is causing SYS.SOURCE$ and
SYS.IDL_UB1$ and the objects cluster to become very large. I don't have
non-SYS owned objects in SYSTEM and I don't have SYS.AUD$ in SYSTEM
either.
Quite simply, we'd need to know more about the OP's database. But I
think that the other advice is a great place to start.
Cheers,
Brian
Snid wrote: If auditing is turned on, then it is possible that your SYS.AUD$ table is growing and since this is in the SYSTEM tablespace it could be responsible for it's size. "Hari Om" <hari_om@hotmail.com> wrote in message news:d1d5ebe4.0309051405.56aca3e5@posting.google.com... | I am using Oracle 9.2.0.1 on IBM AIX 5.1L | | My following Tablespaces are 99% full....is it normal...? do I need to | increase manually or is ti done automatically: | --------------------------------------------------------- | TABLESPACE SIZE USED %USED | --------------------------------------------------------- | SYSTEM 400MB 394MB 98 | EXAMPLE 138MB 137MB 99 | XDB 38MB 37MB 99 | --------------------------------------------------------- | | Do you think increasing the above Tablespace will increase the speed | also? | | Any related informaiton is appreciated. | | (Apologize for my ignorance) | THANKS!
--
===================================================================
Brian Peasland
dba@remove_spam.peasland.com
Remove the "remove_spam." from the email address to email me.
"I can give it to you cheap, quick, and good. Now pick two out of
the three"
Daniel Morgan
09-08-2003, 07:31 AM
Brian Peasland wrote:
While I agree with all of the other posts that non-Data Dictionary itemsshould not be in SYSTEM, and that if auditing is being done thatSYS.AUD$ should be moved to a different tablespace, I feel that sayingthat SYSTEM is too large is doing a slight injustice to the OP. We haveno idea what that database is being used for, what applications arerunning against it, and what objects are stored in the database.It is highly possible for SYSTEM to be 500MB and for it to be that wayon purpose. I have two rather large instances (1TB and 5TB) with 40,000+objects that each have SYSTEM over 500MB. In those cases, it is a largenumber of triggers and stored procs that is causing SYS.SOURCE$ andSYS.IDL_UB1$ and the objects cluster to become very large. I don't havenon-SYS owned objects in SYSTEM and I don't have SYS.AUD$ in SYSTEMeither.Quite simply, we'd need to know more about the OP's database. But Ithink that the other advice is a great place to start.Cheers,BrianSnid wrote:If auditing is turned on, then it is possible that yourSYS.AUD$table is growing and since this is in the SYSTEM tablespace it could beresponsible for it's size."Hari Om" <hari_om@hotmail.com> wrote in messagenews:d1d5ebe4.0309051405.56aca3e5@posting.google.com...| I am using Oracle 9.2.0.1 on IBM AIX 5.1L|| My following Tablespaces are 99% full....is it normal...? do I need to| increase manually or is ti done automatically:| ---------------------------------------------------------| TABLESPACE SIZE USED %USED| ---------------------------------------------------------| SYSTEM 400MB 394MB 98| EXAMPLE 138MB 137MB 99| XDB 38MB 37MB 99| ---------------------------------------------------------|| Do you think increasing the above Tablespace will increase the speed| also?|| Any related informaiton is appreciated.|| (Apologize for my ignorance)| THANKS!
I agree which is why I asked the OP to run a query to identify the
largest segments. That should answer the question.
BTW: Can't we stop cross-posting this one? It has nothing to do with
c.d.o.misc or tools. Lets kill these other threads.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)
Pete Finnigan
09-08-2003, 12:49 PM
Hi Brian,
You mention moving sys.aud$ to another tablespace, whilst this is common
sense Oracle no longer support doing this as some poor customer could
not recover when this had been done. I don't believe Oracle have changed
advice on this as yet. There is a note on Metalink about it. The
solution if it is moved is probably to switch audit off whilst
recovering. Jonathan discussed the following with me some time back:
<snip>
I haven't done any tests on the theory - it was just
a surmise that when the complainant was trying recovery,
they needed to recover the tablespace with the aud$ table
in it, but were running with audit on, so the recovery
processes couldn't log themselves until after the recovery
had completed.
</snip>
kind regards
Pete
should not be in SYSTEM, and that if auditing is being done thatSYS.AUD$ should be moved to a different tablespace, I feel that saying
--
Pete Finnigan
email:pete@petefinnigan.com
Web site: http://www.petefinnigan.com - Oracle security audit specialists
Book:Oracle security step-by-step Guide - see http://store.sans.org for details.
Daniel Morgan
09-09-2003, 07:06 AM
<all snipped>
This thread has nothing to do with misc and tools.
I have responded in c.d.o.server and suggest we try to move the
discussion there where it is on-topic.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)
MyLounge.com Site Map
Forum:
Cars,
Cell Phone,
Database,
Games,
Home Improvement,
IT,
Music,
School,
Sports,
Web Design,
Web Server,
Weight Loss
The MyLounge.com forum is intended for informational use only and should not
be relied upon and is not a substitute for any advice. The information contained
on MyLounge.com are opinions and suggestions of members and is not a representation
of the opinions of MyLounge.com. MyLounge.com does not warrant or vouch for
the accuracy, completeness or usefulness of any postings or the qualifications
of any person responding. Please consult a expert or seek the services of an
attorney in your area for more accuracy on your specific situation. Please note
that our forums also serve as mirrors to Usenet newsgroups. Many posts you see
on our forums are made by newsgroup users who may not be members of MyLounge.com
Term of Service
vBulletin v3.0.7, Copyright ©2000-2009, Jelsoft Enterprises Ltd.