Return-Path: Received: from ensim.rackshack.net (root@localhost) by orafaq.net (8.11.6/8.11.6) with ESMTP id h0KIulc16930 for ; Mon, 20 Jan 2003 12:56:47 -0600 X-ClientAddr: 209.68.248.164 Received: from newsfeed.cts.com (newsfeed.cts.com [209.68.248.164]) by ensim.rackshack.net (8.11.6/8.11.6) with ESMTP id h0KIulp16924 for ; Mon, 20 Jan 2003 12:56:47 -0600 Received: from fatcity.UUCP (uucp@localhost) by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id HAA16649; Mon, 20 Jan 2003 07:38:12 -0800 (PST) Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 005348E1; Mon, 20 Jan 2003 06:55:46 -0800 Message-ID: Date: Mon, 20 Jan 2003 06:55:46 -0800 To: Multiple recipients of list ORACLE-L X-Comment: Oracle RDBMS Community Forum X-Sender: "Tim Gorman" Sender: root@fatcity.com Reply-To: ORACLE-L@fatcity.com Errors-To: ML-ERRORS@fatcity.com From: "Tim Gorman" Subject: Re: 100% CPU utilization, urgent Organization: Fat City Network Services, San Diego, California X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman Precedence: bulk Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BA5_01C2C058.F0B62880" ------=_NextPart_000_0BA5_01C2C058.F0B62880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 100% CPU utilization, urgentIt would be more appropriate to determine = whether SMON is consuming all the CPU first, before sending someone on = some irrelevant wild-goose chase for "fragmented tablespaces". More = effective to first look for basic facts than to go off chasing after any = theories at this point; you might be right, but if you're wrong than a = lot of time has been wasted and confusion sown... --- Since the symptom is CPU usage, then we should look at some of the = information about CPU usage that Oracle stores internally. A quick and = dirty starting point would be to query V$SESSTAT for the STATISTIC# = related to the statistic "CPU used by this session", which you can find = in V$STATNAME: SELECT S.SID, S.PROGRAM, NVL(S.USERNAME, 'SYS'), S.TYPE, T.VALUE FROM V$SESSION S, V$SESSTAT T, V$STATNAME N WHERE N.NAME =3D 'CPU used by this session' AND T.STATISTIC# =3D N.STATISTIC# AND S.SID =3D T.SID ORDER BY T.VALUE DESC; Feel free to post the first 5-10 lines of output from this query back as = a reply to the list, if you'd like us to help interpret it? --- The very best approach is to take a STATSPACK level-5 (default level) = reading during the period of 100% utilization and submit the resulting = "sp_*.lst" file to http://www.oraperf.com for further analysis. If SMON = is the culprit, then you'll see SQL statements consuming tons of time = updating the FET$ and UET$ tables in the SYS schema. Otherwise, follow = the hyperlinks to the "big" percentages to find out what is consuming = most of the resources, especially CPU... If you don't have STATSPACK installed, the next best thing would be to = take a BSTAT/ESTAT report over the same time period when CPU is pegged = at 100% and (again) submit that to www.oraperf.com to get the full YAPP = report. However, BSTAT/ESTAT will not provide information about SQL = statements, so you'll need to find that separately. Best to just = install STATSPACK; there is plenty of information on MetaLink... --- Also, Oracle is supposed to supply some utility called "Performance = Monitor for Windows" which is supposed to be helpful on that platform. = I searched MetaLink briefly but couldn't find explanatory information; = perhaps the standard doc-set on "otn.oracle.com" would have something? Hope this helps... ----- Original Message -----=20 From: Nikunj Gupta=20 To: Multiple recipients of list ORACLE-L=20 Sent: Monday, January 20, 2003 12:38 AM Subject: Re: 100% CPU utilization, urgent Check for fragmented tablespaces... There are chances that SMON is = active and coalescing tablespaces.=20 ----- Original Message -----=20 From: Naveen Nahata=20 To: Multiple recipients of list ORACLE-L=20 Sent: Sunday, January 19, 2003 10:48 PM Subject: RE: 100% CPU utilization, urgent Hussain, We have a similar environment and we also hit 100%CPU utilization at = times. But we never face problem because of tht. the DB keeps working = fine during 100% CPU utilization also. Are you having a problem of logging into the DB during tht time? Regards Naveen -----Original Message----- From: Hussain Ahmed Qadri [mailto:hussain@skm.org.pk] Sent: Monday, January 20, 2003 11:14 AM To: Multiple recipients of list ORACLE-L Subject: 100% CPU utilization, urgent HI all=20 We have a consistent problem of CPU utilization 100%. We have had = this problem since Saturday, but it automatically subsided, I mean went = back to normal after a few hours, and remained normal on Sunday as well. = But its back to 100% since morning, that is when the load on the server = has gone up again to 100% and over all work is non-existent.=20 Our machine is Compaq Proliant ML350, 900 MB ram, 933 single = Processor, Database size of roughly 5 GB. WINNT4.0, Oracle 8.1.7. I have checked the temporary tablespaces, they are normal.=20 We have a 24x7 environment, a hospital, so please can you suggest = the areas to look in to, its really very urgent.=20 Regards,=20 Hussain=20 DISCLAIMER: This message (including attachment if any) is confidential and may = be privileged. Before opening attachments please check them for viruses = and defects. MindTree Consulting Private Limited (MindTree) will not be = responsible for any viruses or defects or any forwarded attachments = emanating either from within MindTree or outside. If you have received = this message by mistake please notify the sender by return e-mail and = delete this message from your system. Any unauthorized use or = dissemination of this message in whole or in part is strictly = prohibited. Please note that e-mails are susceptible to change and = MindTree shall not be liable for any improper, untimely or incomplete = transmission.=20 ------=_NextPart_000_0BA5_01C2C058.F0B62880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 100% CPU utilization, urgent
It would be more appropriate to = determine whether=20 SMON is consuming all the CPU first, before sending someone on some = irrelevant wild-goose chase for "fragmented = tablespaces".  More=20 effective to first look for basic facts than to go off chasing after any = theories at this point;  you might be right, but if you're = wrong than=20 a lot of time has been wasted and confusion sown...
 
---
 
Since the symptom is CPU usage, = then we should=20 look at some of the information about CPU usage that Oracle stores=20 internally.  A quick and dirty starting point would be to = query=20 V$SESSTAT for the STATISTIC# related to the statistic "CPU used by this=20 session", which you can find in V$STATNAME:
SELECT   S.SID, = S.PROGRAM,=20 NVL(S.USERNAME, 'SYS'), S.TYPE, = T.VALUE
FROM    =20 V$SESSION S, V$SESSTAT T, V$STATNAME N
WHERE    = N.NAME =3D=20 'CPU used by this session'
AND      = T.STATISTIC# =3D=20 N.STATISTIC#
AND      S.SID =3D=20 T.SID
ORDER    BY T.VALUE = DESC;
Feel free to post the first 5-10 lines = of output=20 from this query back as a reply to the list, if you'd like us to help = interpret=20 it?
 
---
 
The very best approach is to take a = STATSPACK=20 level-5 (default level) reading during the period of 100% utilization = and submit=20 the resulting "sp_*.lst" file to http://www.oraperf.com for further=20 analysis.  If SMON is the culprit, then you'll see SQL statements = consuming=20 tons of time updating the FET$ and UET$ tables in the SYS schema. =20 Otherwise, follow the hyperlinks to the "big" percentages to find out = what is=20 consuming most of the resources, especially CPU...
 
If you don't have STATSPACK installed, = the next=20 best thing would be to take a BSTAT/ESTAT report over the same time = period when=20 CPU is pegged at 100% and (again) submit that to www.oraperf.com to get the full YAPP = report.  However, BSTAT/ESTAT will not provide information about = SQL=20 statements, so you'll need to find that separately.  Best to just = install=20 STATSPACK;  there is plenty of information on = MetaLink...
 
---
 
Also, Oracle is supposed to supply some utility called "Performance = Monitor=20 for Windows" which is supposed to be helpful on that platform.  I = searched=20 MetaLink briefly but couldn't find explanatory information;  = perhaps the=20 standard doc-set on "otn.oracle.com" would have something?
 
Hope this helps...
----- Original Message -----
From:=20 Nikunj=20 Gupta
Sent: Monday, January 20, 2003 = 12:38=20 AM
Subject: Re: 100% CPU = utilization,=20 urgent

Check for fragmented tablespaces... = There are=20 chances that SMON is active and coalescing tablespaces.
 
----- Original Message -----
From:=20 Naveen Nahata
Sent: Sunday, January 19, = 2003 10:48=20 PM
Subject: RE: 100% CPU = utilization,=20 urgent

Hussain,
 
We=20 have a similar environment and we also hit 100%CPU utilization at = times. But=20 we never face problem because of tht. the DB keeps working fine = during 100%=20 CPU utilization also.
 
Are you having a problem of logging into = the DB=20 during tht time?
 
Regards
Naveen
-----Original Message-----
From: Hussain Ahmed = Qadri=20 [mailto:hussain@skm.org.pk]
Sent: Monday, January 20, = 2003 11:14=20 AM
To: Multiple recipients of list = ORACLE-L
Subject:=20 100% CPU utilization, urgent

HI all
We have a = consistent=20 problem of CPU utilization 100%. We have had this problem since = Saturday,=20 but it automatically subsided, I mean went back to normal after a = few=20 hours, and remained normal on Sunday as well. But its back to 100% = since=20 morning, that is when the load on the server has gone up again to = 100% and=20 over all work is non-existent.

Our machine is Compaq Proliant ML350, 900 MB = ram, 933=20 single Processor, Database size of roughly 5 GB. WINNT4.0, Oracle=20 8.1.7.

I have checked the temporary tablespaces, they = are=20 normal.
We have a 24x7 environment, a = hospital, so=20 please can you suggest the areas to look in to, its really very=20 urgent.

Regards,

Hussain

DISCLAIMER:
This message (including attachment if any) is = confidential=20 and may be privileged. Before opening attachments please check them = for=20 viruses and defects. MindTree Consulting Private Limited (MindTree) = will not=20 be responsible for any viruses or defects or any forwarded = attachments=20 emanating either from within MindTree or outside. If you have = received this=20 message by mistake please notify the sender by return e-mail and = delete this=20 message from your system. Any unauthorized use or dissemination of = this=20 message in whole or in part is strictly prohibited. Please note that = e-mails=20 are susceptible to change and MindTree shall not be liable for any = improper,=20 untimely or incomplete transmission.=20

------=_NextPart_000_0BA5_01C2C058.F0B62880-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tim Gorman INET: Tim@SageLogix.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).