WITH vs INNER QUERY on 11g (100% CPU & Never Return vs 2-3 Seconds)

I cannot figure out why this is happening. We have an 11g database and a pipelined stored function. The following will never return. The db cpu goes up to about 100%.
FOR myRow IN (
  WITH subquery AS (
    SELECT ...
  SELECT
  FROM subqery
LOOP
  PIPE ROW(...);
END LOOP;If it's formatted the following way, it behaves the same way...:
FOR myRow IN (
  SELECT
  FROM (
    SELECT ...
LOOP
  PIPE ROW(...);
END LOOP;However, using the SELECT * FROM (...) method, without the procedure, returns fine:
SELECT * FROM (
  SELECT * FROM (
)But this never returns:
WITH subquery AS (
  SELECT ...
SELECT
FROM subqueryI have no idea how to diagnose this. It's as if one method tries to store results one way, while the other does not. Any thoughts would be greatly appreciated!!

This is the explain for the /*+materialize*/ and subquery form:
Plan hash value: 2761872157
| Id  | Operation                  | Name                      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT           |                           |     1 |   130 |       |  3427   (2)| 00:00:42 |
|   1 |  TEMP TABLE TRANSFORMATION |                           |       |       |       |            |          |
|   2 |   LOAD AS SELECT           |                           |       |       |       |            |          |
|*  3 |    HASH JOIN               |                           |     5 |  1090 |       |  3425   (2)| 00:00:42 |
|   4 |     TABLE ACCESS FULL      | U_MASTER                  |   579 |  4632 |       |     5   (0)| 00:00:01 |
|*  5 |     HASH JOIN RIGHT OUTER  |                           | 83280 |    16M|  4152K|  3418   (2)| 00:00:42 |
|   6 |      VIEW                  |                           | 83280 |  3171K|       |   857   (2)| 00:00:11 |
|*  7 |       HASH JOIN            |                           | 83280 |  4066K|       |   857   (2)| 00:00:11 |
|*  8 |        TABLE ACCESS FULL   | U_MASTER                  |   246 |  1722 |       |     5   (0)| 00:00:01 |
|   9 |        VIEW                |                           | 83280 |  3497K|       |   851   (2)| 00:00:11 |
|* 10 |         HASH JOIN          |                           | 83280 |  3903K|  2704K|   851   (2)| 00:00:11 |
|* 11 |          TABLE ACCESS FULL | T_MASTER                  | 78886 |  1771K|       |   377   (2)| 00:00:05 |
|* 12 |          TABLE ACCESS FULL | T_CONTAINER_IN            | 84469 |  2062K|       |   191   (3)| 00:00:03 |
|* 13 |      HASH JOIN OUTER       |                           | 83280 |    13M|  1048K|  1634   (2)| 00:00:20 |
|  14 |       TABLE ACCESS FULL    | C_MASTER                  | 16742 |   850K|       |   127   (2)| 00:00:02 |
|  15 |       VIEW                 |                           | 83280 |  9678K|       |   937   (2)| 00:00:12 |
|* 16 |        HASH JOIN           |                           | 83280 |  9678K|       |   937   (2)| 00:00:12 |
|* 17 |         TABLE ACCESS FULL  | U_MASTER                  |   246 |  2706 |       |     5   (0)| 00:00:01 |
|  18 |         VIEW               |                           | 83280 |  8783K|       |   931   (2)| 00:00:12 |
|* 19 |          HASH JOIN         |                           | 83280 |  5530K|  2704K|   931   (2)| 00:00:12 |
|* 20 |           TABLE ACCESS FULL| T_MASTER                  | 78886 |  1771K|       |   377   (2)| 00:00:05 |
|* 21 |           TABLE ACCESS FULL| T_CONTAINER_IN            | 84469 |  3712K|       |   191   (3)| 00:00:03 |
|  22 |   VIEW                     |                           |     1 |   130 |       |     2   (0)| 00:00:01 |
|  23 |    TABLE ACCESS FULL       | SYS_TEMP_0FD9D670A_23115C |     1 |   103 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("A"."PICKUP_LOC_UNIT"="B"."U_ID")
       filter(("A"."STATUS"=1 OR "A"."STATUS"=2) AND "B"."FAC_ID"=161 AND
              "from$_subquery$_008"."TO_UNIT_ID" IS NULL AND SYS_EXTRACT_UTC(INTERNAL_FUNCTION("A"."ORIGIN_DATETIME"))
              <=SYS_EXTRACT_UTC(SYSTIMESTAMP(6)) OR "B"."FAC_ID"=161 AND "from$_subquery$_008"."PREV_T_ID" IS NULL
              AND SYS_EXTRACT_UTC(INTERNAL_FUNCTION("from$_subquery$_008"."TASK_DATE_TIME"))>SYS_EXTRACT_UTC(SYSTIMEST
              AMP(6)) AND SYS_EXTRACT_UTC(INTERNAL_FUNCTION("A"."ORIGIN_DATETIME"))<=SYS_EXTRACT_UTC(SYSTIMESTAMP(6))
              AND "from$_subquery$_008"."TO_UNIT_ID" IS NOT NULL OR "from$_subquery$_008"."FAC_ID"=161 AND
              "from$_subquery$_014"."TASK_DATE_TIME" IS NULL AND ("from$_subquery$_008"."UNIT_TYPE_ID"=2 OR
              "from$_subquery$_008"."UNIT_TYPE_ID"=3) AND SYS_EXTRACT_UTC(INTERNAL_FUNCTION("from$_subquery$_008"."TAS
              K_DATE_TIME"))<=SYS_EXTRACT_UTC(SYSTIMESTAMP(6)) OR "from$_subquery$_008"."FAC_ID"=161 AND
              ("from$_subquery$_008"."UNIT_TYPE_ID"=2 OR "from$_subquery$_008"."UNIT_TYPE_ID"=3) AND
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("from$_subquery$_008"."TASK_DATE_TIME"))<=SYS_EXTRACT_UTC(SYSTIMESTAMP
              (6)) AND SYS_EXTRACT_UTC(INTERNAL_FUNCTION("from$_subquery$_014"."TASK_DATE_TIME"))>SYS_EXTRACT_UTC(SYST
              IMESTAMP(6)))
   5 - access("from$_subquery$_008"."QCSJ_C000000000600000"="G"."PREV_T_ID"(+) AND
              "from$_subquery$_008"."C_ID_IN"="G"."C_ID_IN"(+))
   7 - access("H"."TO_UNIT_ID"="I"."U_ID")
   8 - filter("I"."UNIT_TYPE_ID"=1 OR "I"."UNIT_TYPE_ID"=2 OR "I"."UNIT_TYPE_ID"=3)
  10 - access("G"."T_ID"="H"."T_ID")
  11 - filter("H"."STATUS"=1)
  12 - filter("G"."REJECT"=0)
  13 - access("A"."C_ID"="C"."C_ID_IN"(+))
  16 - access("D"."TO_UNIT_ID"="E"."U_ID")
  17 - filter("E"."UNIT_TYPE_ID"=1 OR "E"."UNIT_TYPE_ID"=2 OR "E"."UNIT_TYPE_ID"=3)
  19 - access("C"."T_ID"="D"."T_ID")
  20 - filter("D"."STATUS"=1)
  21 - filter("C"."REJECT"=0) This is the explain for the with statement form (the one that never returns):
  Plan hash value: 868902620
| Id  | Operation                        | Name                         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                 |                              |     5 |   840 |       |  1493   (2)| 00:00:18 |
|*  1 |  FILTER                          |                              |       |       |       |            |          |
|   2 |   NESTED LOOPS OUTER             |                              |     5 |   840 |       |  1493   (2)| 00:00:18 |
|*  3 |    HASH JOIN                     |                              | 83280 |    11M|       |  1484   (2)| 00:00:18 |
|   4 |     TABLE ACCESS FULL            | U_MASTER                     |   579 |  4632 |       |     5   (0)| 00:00:01 |
|*  5 |     HASH JOIN OUTER              |                              | 83280 |    10M|  1048K|  1477   (2)| 00:00:18 |
|   6 |      TABLE ACCESS FULL           | C_MASTER                     | 16742 |   850K|       |   127   (2)| 00:00:02 |
|   7 |      VIEW                        |                              | 83280 |  6424K|       |   937   (2)| 00:00:12 |
|*  8 |       HASH JOIN                  |                              | 83280 |  6424K|       |   937   (2)| 00:00:12 |
|*  9 |        TABLE ACCESS FULL         | U_MASTER                     |   246 |  2706 |       |     5   (0)| 00:00:01 |
|* 10 |        HASH JOIN                 |                              | 83280 |  5530K|  2704K|   931   (2)| 00:00:12 |
|* 11 |         TABLE ACCESS FULL        | T_MASTER                     | 78886 |  1771K|       |   377   (2)| 00:00:05 |
|* 12 |         TABLE ACCESS FULL        | T_CONTAINER_IN               | 84469 |  3712K|       |   191   (3)| 00:00:03 |
|* 13 |    VIEW PUSHED PREDICATE         |                              |     1 |    29 |       |     0   (0)| 00:00:01 |
|* 14 |     HASH JOIN                    |                              |   845 | 46475 |       |   384   (2)| 00:00:05 |
|* 15 |      TABLE ACCESS FULL           | U_MASTER                     |   246 |  1722 |       |     5   (0)| 00:00:01 |
|  16 |      NESTED LOOPS                |                              |       |       |       |            |          |
|  17 |       NESTED LOOPS               |                              |   845 | 40560 |       |   378   (2)| 00:00:05 |
|* 18 |        TABLE ACCESS FULL         | T_MASTER                     | 78886 |  1771K|       |   377   (2)| 00:00:05 |
|* 19 |        INDEX RANGE SCAN          | IDX_T_CONTAINER_IN_PREV_T_ID |     1 |       |       |     0   (0)| 00:00:01 |
|* 20 |       TABLE ACCESS BY INDEX ROWID| T_CONTAINER_IN               |     1 |    25 |       |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter(("A"."STATUS"=1 OR "A"."STATUS"=2) AND "B"."FAC_ID"=161 AND "from$_subquery$_008"."TO_UNIT_ID" IS
              NULL AND SYS_EXTRACT_UTC(INTERNAL_FUNCTION("A"."ORIGIN_DATETIME"))<=SYS_EXTRACT_UTC(SYSTIMESTAMP(6)) OR
              "B"."FAC_ID"=161 AND "from$_subquery$_008"."PREV_T_ID" IS NULL AND
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("from$_subquery$_008"."TASK_DATE_TIME"))>SYS_EXTRACT_UTC(SYSTIMESTAMP(6)) AND
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("A"."ORIGIN_DATETIME"))<=SYS_EXTRACT_UTC(SYSTIMESTAMP(6)) AND
              "from$_subquery$_008"."TO_UNIT_ID" IS NOT NULL OR "from$_subquery$_008"."FAC_ID"=161 AND
              "from$_subquery$_014"."TASK_DATE_TIME" IS NULL AND ("from$_subquery$_008"."UNIT_TYPE_ID"=2 OR
              "from$_subquery$_008"."UNIT_TYPE_ID"=3) AND SYS_EXTRACT_UTC(INTERNAL_FUNCTION("from$_subquery$_008"."TASK_DATE_TI
              ME"))<=SYS_EXTRACT_UTC(SYSTIMESTAMP(6)) OR "from$_subquery$_008"."FAC_ID"=161 AND
              ("from$_subquery$_008"."UNIT_TYPE_ID"=2 OR "from$_subquery$_008"."UNIT_TYPE_ID"=3) AND
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("from$_subquery$_008"."TASK_DATE_TIME"))<=SYS_EXTRACT_UTC(SYSTIMESTAMP(6)) AND
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("from$_subquery$_014"."TASK_DATE_TIME"))>SYS_EXTRACT_UTC(SYSTIMESTAMP(6)))
   3 - access("A"."PICKUP_LOC_UNIT"="B"."U_ID")
   5 - access("A"."C_ID"="C"."C_ID_IN"(+))
   8 - access("D"."TO_UNIT_ID"="E"."U_ID")
   9 - filter("E"."UNIT_TYPE_ID"=1 OR "E"."UNIT_TYPE_ID"=2 OR "E"."UNIT_TYPE_ID"=3)
  10 - access("C"."T_ID"="D"."T_ID")
  11 - filter("D"."STATUS"=1)
  12 - filter("C"."REJECT"=0)
  13 - filter("from$_subquery$_008"."C_ID_IN"="G"."C_ID_IN"(+))
  14 - access("H"."TO_UNIT_ID"="I"."U_ID")
  15 - filter("I"."UNIT_TYPE_ID"=1 OR "I"."UNIT_TYPE_ID"=2 OR "I"."UNIT_TYPE_ID"=3)
  18 - filter("H"."STATUS"=1)
  19 - access("G"."PREV_T_ID"="from$_subquery$_008"."QCSJ_C000000000600000")
  20 - filter("G"."REJECT"=0 AND "G"."T_ID"="H"."T_ID")Just wanted to say thanks again for any additional help you can provide!
Edited by: asmallgrin on Feb 3, 2010 7:28 AM

Similar Messages

  • Sessions with Event "class slave wait" taking 100% CPU

    Hi experts,
    I have an issue in an 11.2.0.2 RAC database with 2 standby nodes that are driving me nuts.
    All started when I've been told there are 2 Oracle processes consuming too much CPU in the environment.
    I found 2 processes which takes 100% CPU each. These processes are Oracle processes into the DB and checking them out although they are registered in v$process and v$session, there is nothing related to them in v$bgprocess so I could not find out which oracle processes started these 2 OS processes.
    The view v$session shows them ACTIVE in the event "class slave wait". There aren't too much information about this event, at least I failed to find...
    Using dbms_monitor and dbms_system to create trace events did not create any tracefile. Only ORADEBUG was able to create events but with nearly no information inside the trace files.
    Questions I need to have answered or at least hints that I can follow to find the answer:
    1) what is causing the CPUs to be consumed at 100%? Which process?
    2) Why does these processes are using that much of CPU?
    3) What can be done to safely get over it?
    Honestly I don't know where else to look at except trying to get some help. Could someone give me a hand please?
    BR,
    Lauro Ojeda
    Edited by: LauroOjeda on 26/01/2013 06:44

    Hi Pal, thanks for your reply!
    Here are the answers:
    1. If it is RAC there is no such construct as a "standby node" and you say you have two of them. Please be specific ... is this RAC or Data Guard or a combination? Or do you have a three node cluster with all services pointing to only a single server wasting all of the resources of the other three?
    A: This is a combination of them. We have 2 nodes in a RAC environment shipping logs to two physical standby databases in another site.
    2. Two processes can not be at 100% of CPU any more than I can be 200% awake. Please show us how you arrived at this conclusion, on what hardware and operating system, and include a formatted (read the FAQ to learn how) extract showing what you are seeing.
    A: top in Linux shows two oracle processes consuming 100% (or nearly of it) of 1 CPU each. This is a 16 cores server (each primary node) so 2 of these are working on full capacity to service the described processes.
    3. What processes? Name them and again run a SQL statement and post the output so we can see what you are looking at.
    A: Like I said before I failed to find which background process they belongs to as there are no indications of them in v$bgprocess and in v$session/v$process either. I can see them in v$process and v$session but again, there are no indications of for which bg process they belong to.
    4. Is anything slow? Are there any problems with the system or are you only reacting to two numbers you think are too high?
    A: No, system is not slow because of that but the client wants to investigate and have it sorted as it is not normal.
    Additionally I found a bug in metalink which seems to be the culprit, but I'm unsure yet. This is Bug 12929268 : HIGH CPU ON ORA_O00N PROCESS
    Is any other information that I may provide you?
    Thanks for help!
    Lauro Ojeda

  • Quicktime doesnt start (process 100% cpu, never appears)

    I'm having weird problems with Quicktime (and iTunes too).
    When i open a .mov file in quicktime (Win XP sp2), the quicktimeplayer.exe process immediately uses 100% CPU and the user interface never appears. I have to kill the process in the taskmanager.
    if i go to windows' configuration panel, and i click [Quicktime], the rundll32.exe process uses 100% cpu (this is the quicktime config screen).
    When i launch itunes, the same happens.
    When i open a website containing a quicktime movie in IE or Firefox -> same.
    I tried reinstalling older versions of quicktime, i tried downloading the unregistered free version from apple.com, i tried the unofficial [quicktime alternative] program, and they all produce the same result.
    Sometimes, after the setup is completed, i can watch .mov files, but usually only for a while, after that the problem is back.
    I uninstalled all quicktime/itunes related applications before reinstalling, deleted every trace of QT stuff on my harddisk, and even registry. But the problem keeps coming back.
    Environment:
    Windows XP professional SP2 (fully updated, in perfect condition)
    GeForce FX5600 videocard (latest drivers)
    3GHZ cpu / 1000MB ram
    Plenty of free HD space, no spyware or any other crap, no antivirus or other programs running.
    I have no idea what "triggered" this problem, maybe it was a windows update, maybe a gfxcard update, or maybe it's an overdue y2k problem.
    probably unimportant note: When i say 100% cpu, i actually mean 50% but this is only because my processor uses Intel Hyperthreading.
      Windows XP Pro  

    I'm having weird problems with Quicktime (and iTunes too).
    When i open a .mov file in quicktime (Win XP sp2), the quicktimeplayer.exe process immediately uses 100% CPU and the user interface never appears. I have to kill the process in the taskmanager.
    if i go to windows' configuration panel, and i click [Quicktime], the rundll32.exe process uses 100% cpu (this is the quicktime config screen).
    When i launch itunes, the same happens.
    When i open a website containing a quicktime movie in IE or Firefox -> same.
    I tried reinstalling older versions of quicktime, i tried downloading the unregistered free version from apple.com, i tried the unofficial [quicktime alternative] program, and they all produce the same result.
    Sometimes, after the setup is completed, i can watch .mov files, but usually only for a while, after that the problem is back.
    I uninstalled all quicktime/itunes related applications before reinstalling, deleted every trace of QT stuff on my harddisk, and even registry. But the problem keeps coming back.
    Environment:
    Windows XP professional SP2 (fully updated, in perfect condition)
    GeForce FX5600 videocard (latest drivers)
    3GHZ cpu / 1000MB ram
    Plenty of free HD space, no spyware or any other crap, no antivirus or other programs running.
    I have no idea what "triggered" this problem, maybe it was a windows update, maybe a gfxcard update, or maybe it's an overdue y2k problem.
    probably unimportant note: When i say 100% cpu, i actually mean 50% but this is only because my processor uses Intel Hyperthreading.
      Windows XP Pro  

  • RV180W with Firmware 1.0.3.10 - 100% CPU Problem

    Hi,
    Since I updated my Firmware to version 1.0.3.10 my CPU is showing up as 100% used.  I seen a discussion about this issue on previous firmware 1.0.2.6 but I would assume that this issue has been addressed by Cisco.  This products firmware appears to be very buggy with many of the bugs not being sorted with updated firmwares.  Are Cisco dropping the ball on their Small Business range of products.  I for one am not very happy to see known bugs from previous Firmwares remaining after updates. Release notes for FW 1.0.3.11 show the following:
    Issues Carried Over from 1.0.2.6
    CSCuc72086 Description—Port forwarding in regards to port range
    does not work.
    Workaround—Use a single port instead of a port range.
    CSCuc55834 Description—Selected smart phones have an
    interoperability issue where either the PIN or PBC method
    will not work for Wi-Fi Protected Setup (WPS).
    Workaround—If one method does not work, try the other
    method or revert back to the conventional Wi-Fi setting.
    CSCtr24497 Description—Traffic does not follow the bandwidth limit
    when the traffic selector is set to VLAN, DSCP or SSID.
    Workaround—Use an IP range instead. To edit a profile
    binding rule, go to the QoS > Profile Binding page, find the
    rule in the table, and then click Edit. On the Add / Edit
    Profile Binding Configuration page, Traffic Selector Match
    Type field, select IP Address Range, and then enter the
    starting and ending addresses.
    CSCtt41705 Description—On the Status > Port Statistics page, the
    statistics in the Packets column are not updating to show
    the current number of transmitted and received packets.
    Workaround—None.
    CSCtq78773 Description—Enabling or disabling multiple SSIDs at once
    is taking longer than 1 minute.
    Workaround—None
    This is something you expect from other manufacturers not CISCO. Does this products code need to be stripped back and rewritten to eventually solve some of the bugs in it.  Patches just don't seem to be resolving enough of the current issues.
    Any ideas Cisco?

    While I have the RV180 (not RV180W), I fully agree.
    When I reset or reboot the RV180, the reboot counter starts at 150 seconds.  But it takes another 20-30 seconds AFTER this counter expires before the LAN activates.  And if I log into the RV180 at around 180 seconds after reboot it shows the CPU at over 90%.  If I try doing any configuration followed by a reboot at this point there is a good chance there will be problems.
    For example I have been playing with IPv6 throught a 6to4 tunnel on the RV180.  Enabling IPv6 requires a reboot.  So if I do a factory reset (causing a reboot), then do a quick setup (enable PPPoE connection, enable pings, don't block anon ICMP), then enable IPv6 (causing another reboot)...
    If I do the quick setup and enable IPv6 reboot as soon as I can log onto the RV180 (about 180 second after factory reset), sometimes there will be something wrong after the second reboot.  For example I have had the PPPoE not take and the RV180 set back to DHCP.  I have also had it show a strange MAC adress for both the WAN and the LAN (this has happened more than once although when it happens it always shows the same WRONG MAC address).
    Now if I wait and extra 2-3 minutes (so 5-6 minutes after a reboot) before doing any configurations, or rebooting the RV180, or turning off the RV180, chances for problems seems to be greatly reduced.  Although even after 5-6 minutes the CPU is still over 70%.
    All this seems to indicate that the RV180 is really struggling with the current firmware.  It really shouldn't take more than a minute or so for the RV180 to reboot and be ready for configuration.  I don't know if this means the code needs to be stripped back and rewritten, or if maybe the OS just needs to be changed to a more streamlined OS.
    Although the best first step might be to find a programmer actually INTERESTED in working on the RV180 and RV180W.

  • 100% CPU Usage Overhead running EM DBConsole 11g on OEL-5.2

    After upgrading to OEL-5.2 and relinking all Oracle binaries, my old Oracle 11g installation, installed several months before on OEL-5.1, has been working well, including Enterprise Manager Database Console working nicely as always with respectful performance. Unfortunatelly, it lasted just several days.
    Yesterday I decided to uninstall the 11g completely and perform new clean installation (software and database) with the same configuration options and settings as before, including EM dbconsole, all configured using dbca. After completing the installation (EM was started automatically by dbca), oracle continued to suck 80-85% CPU time. In further few minutes CPU utilization raised up to 99% due to only one (always the same PID) client process - "oracleorcl (LOCAL=NO)". For first ten minutes I didn't care too much since I always enable Automatic Management in dbca. But after two hours, I started to worry. The process was still running, consuming sustained 99% of CPU power. No other system activity, no database activity, no disks activity at all!
    I was really puzzled since I installed and reinstalled the 11g at least 20 times on OEL-5.0 and 5.1, experimenting with ASM, raw devices, loopback devices and various combinations of installation options, but never experienced such a behaviour. It took me 3 minutes to log in to EM dbconsole as it was almost unusable performing too slow. After three hours CPU temperature was nearly 60 degrees celsius. I decided to shutdown EM and after that everything became quiet. Oracle was running normally. Started EM again, the problem was back again. Tracing enabled, it filled a 350 MB trace file in just 20 minutes. Reinstalling the software and database once again didn't help. Whenever EM is up, the CPU usage overhead of 99% persists.
    Here is a cca 23 minutes session summary report taken from EM dbconsole's Performance page. The trace file is too big to list it here, but it shows the same.
            Host CPU:  100%
    Active Sessions:  100%The details for the Selected 5 Minute Interval (the last 5 min interval) are shown as follow:
        TOP SESSIONS:  SYSMAN, Program: OMS
            Activity:  100%  
         TOP MODULES:  OEM.CacheModeWaitPool, Service: orcl
            Activity:  100%          
          TOP CLIENT:  Unnamed
            Activity:  99.1%
         TOP ACTIONS:  Unnamed (OEM.CacheModeWaitPool) (orcl)
            Activity:  100%
         TOP OBJECTS: SYSMAN.MGMT_JOB_EXEC_SUMMARY (Table)
            Activity:  100%
          TOP PL/SQL:  SYSMAN.MGMT_JOB_ENGINE.INSERT_EXECUTION
       PL/SQL Source:  SYSMAN.MGMT_JOB_ENGINE
         Line Number:  7135
            Activity:  100%
             TOP SQL:  SELECT EXECUTION_ID, STATUS, STATUS_DETAIL FROM MGMT_JOB_EXEC_SUMMARY
    WHERE JOB_ID = :B3 AND TARGET_LIST_INDEX = :B2 AND EXPECTED_START_TIME = :B1;
            Activity:  100%
                                  STATISTICS SUMMARY
                                cca 23 minutes session
                            with no other system activity
                                            Per 
                           Total      Execution         Per Row
    Executions           105,103                 1       10,510.30
    Elapsed Time (sec)  1,358.95              0.01        135.90
    CPU Time (sec)      1,070.42             0.01        107.04
    Buffer Gets       85,585,518 814.30 8,558,551.80
    Disk Reads                 2            <0.01          0.20
    Direct Writes              0              0.00          0.00
    Rows                      10            <0.01             1
    Fetches              105,103             1.00     10,510.30
                       ----------------------------------------Wow!!! Note: no disk, no database activity !
    Has anyone experienced this or similar behaviour after clean 11g installation on OEL-5.2? If not, anyone has a clue what the hell is going on?
    Thanks in advance.

    Hi Tommy,
    I didn't want to experiment further with already working OEL-5.2, oracle and dbconsole on this machine, specially not after googling the problem and finding out that I am not alone in this world. There are another two threads on OTN forums (Database General) showing the same problem even on 2GB machines:
    DBConsole easting a CPU
    11g stuck. 50-100% CPU after fresh install
    So, I took another, a smaller free machine I've got at home (1GB RAM, 2.2MHz Pentium4, three 80GB disks), on which I used to experiment with new releases of software (this is the machine on which I installed 11g for the first time when it was released on OEL-5.0, and I can recall that everything was OK with EM). This is what I did:
    1. I installed OEL-5.0 on the machine, adjusted linux and kernel parameters, and performed full 11g installation. Database and EM dbconsole worked nice with acceptable performance. Without activity in the database, %CPU = zero !!! The whole system was perfectly quiet.
    2. Since everything was OK, I shutdown EM and oracle, and performed the full upgrade to OEL-5.2. When the upgrade finished, restarted the system, relinked all oracle binaries, and started oracle and EM dbconsole. Both worked perfectly again, just as before the upgrade. I repeated restarting the database and dbconsole several times, always with the same result - it really rocks. Without database activity, %CPU = zero%.
    3. Using dbca, I dropped the database and created the new one with the same configuration options. Wow! I'm again in trouble. A half an hour after the creation of the database, %CPU raised up to 99%. That's it.
    The crucial question here is: what is that in OEL-5.2, not existing in the 5.0, that causes dbca/em scripts to be embarrassed at the time of EM agent configuration?
    Here are the outputs you required picked 30 minutes after starting the database and EM dbconsole (sustained 99% CPU utilization). Note that this is just a 1GB machine.
    Kernel command line: ro root=LABEL=/ elevator=deadline rhgb quiet
    [root@localhost ~]# cat /proc/meminfo
    MemTotal:      1034576 kB
    MemFree:         27356 kB
    Buffers:          8388 kB
    Cached:         609660 kB
    SwapCached:      18628 kB
    Active:         675376 kB
    Inactive:       287072 kB
    HighTotal:      130304 kB
    HighFree:          260 kB
    LowTotal:       904272 kB
    LowFree:         27096 kB
    SwapTotal:     3148700 kB
    SwapFree:      2940636 kB
    Dirty:              72 kB
    Writeback:           0 kB
    AnonPages:      328700 kB
    Mapped:         271316 kB
    Slab:            21136 kB
    PageTables:      14196 kB
    NFS_Unstable:        0 kB
    Bounce:              0 kB
    CommitLimit:   3665988 kB
    Committed_AS:  1187464 kB
    VmallocTotal:   114680 kB
    VmallocUsed:      5860 kB
    VmallocChunk:   108476 kB
    HugePages_Total:     0
    HugePages_Free:      0
    HugePages_Rsvd:      0
    Hugepagesize:     4096 kB
    [root@localhost ~]# cat /proc/slabinfo
    slabinfo - version: 2.1
    # name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
    rpc_buffers            8      8   2048    2    1 : tunables   24   12    8 : slabdata      4      4      0
    rpc_tasks              8     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    rpc_inode_cache        6      7    512    7    1 : tunables   54   27    8 : slabdata      1      1      0
    ip_conntrack_expect    0      0     96   40    1 : tunables  120   60    8 : slabdata      0      0      0
    ip_conntrack          68     68    228   17    1 : tunables  120   60    8 : slabdata      4      4      0
    ip_fib_alias           7    113     32  113    1 : tunables  120   60    8 : slabdata      1      1      0
    ip_fib_hash            7    113     32  113    1 : tunables  120   60    8 : slabdata      1      1      0
    fib6_nodes            22    113     32  113    1 : tunables  120   60    8 : slabdata      1      1      0
    ip6_dst_cache         13     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    ndisc_cache            1     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    RAWv6                  4      5    768    5    1 : tunables   54   27    8 : slabdata      1      1      0
    UDPv6                  9     12    640    6    1 : tunables   54   27    8 : slabdata      2      2      0
    tw_sock_TCPv6          0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    request_sock_TCPv6     0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    TCPv6                  1      3   1280    3    1 : tunables   24   12    8 : slabdata      1      1      0
    jbd_1k                 0      0   1024    4    1 : tunables   54   27    8 : slabdata      0      0      0
    dm_mpath               0      0     28  127    1 : tunables  120   60    8 : slabdata      0      0      0
    dm_uevent              0      0   2460    3    2 : tunables   24   12    8 : slabdata      0      0      0
    dm_tio                 0      0     16  203    1 : tunables  120   60    8 : slabdata      0      0      0
    dm_io                  0      0     20  169    1 : tunables  120   60    8 : slabdata      0      0      0
    jbd_4k                 1      1   4096    1    1 : tunables   24   12    8 : slabdata      1      1      0
    scsi_cmd_cache        10     10    384   10    1 : tunables   54   27    8 : slabdata      1      1      0
    sgpool-128            36     36   2048    2    1 : tunables   24   12    8 : slabdata     18     18      0
    sgpool-64             33     36   1024    4    1 : tunables   54   27    8 : slabdata      9      9      0
    sgpool-32             34     40    512    8    1 : tunables   54   27    8 : slabdata      5      5      0
    sgpool-16             35     45    256   15    1 : tunables  120   60    8 : slabdata      3      3      0
    sgpool-8              60     60    128   30    1 : tunables  120   60    8 : slabdata      2      2      0
    scsi_io_context        0      0    104   37    1 : tunables  120   60    8 : slabdata      0      0      0
    ext3_inode_cache    4376   8216    492    8    1 : tunables   54   27    8 : slabdata   1027   1027      0
    ext3_xattr           165    234     48   78    1 : tunables  120   60    8 : slabdata      3      3      0
    journal_handle         8    169     20  169    1 : tunables  120   60    8 : slabdata      1      1      0
    journal_head         684   1008     52   72    1 : tunables  120   60    8 : slabdata     14     14      0
    revoke_table          18    254     12  254    1 : tunables  120   60    8 : slabdata      1      1      0
    revoke_record          0      0     16  203    1 : tunables  120   60    8 : slabdata      0      0      0
    uhci_urb_priv          0      0     28  127    1 : tunables  120   60    8 : slabdata      0      0      0
    UNIX                  56    112    512    7    1 : tunables   54   27    8 : slabdata     16     16      0
    flow_cache             0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    cfq_ioc_pool           0      0     92   42    1 : tunables  120   60    8 : slabdata      0      0      0
    cfq_pool               0      0     96   40    1 : tunables  120   60    8 : slabdata      0      0      0
    crq_pool               0      0     44   84    1 : tunables  120   60    8 : slabdata      0      0      0
    deadline_drq         140    252     44   84    1 : tunables  120   60    8 : slabdata      3      3      0
    as_arq                 0      0     56   67    1 : tunables  120   60    8 : slabdata      0      0      0
    mqueue_inode_cache     1      6    640    6    1 : tunables   54   27    8 : slabdata      1      1      0
    isofs_inode_cache      0      0    368   10    1 : tunables   54   27    8 : slabdata      0      0      0
    hugetlbfs_inode_cache  1     11    340   11    1 : tunables   54   27    8 : slabdata      1      1      0
    ext2_inode_cache       0      0    476    8    1 : tunables   54   27    8 : slabdata      0      0      0
    ext2_xattr             0      0     48   78    1 : tunables  120   60    8 : slabdata      0      0      0
    dnotify_cache          2    169     20  169    1 : tunables  120   60    8 : slabdata      1      1      0
    dquot                  0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    eventpoll_pwq          1    101     36  101    1 : tunables  120   60    8 : slabdata      1      1      0
    eventpoll_epi          1     30    128   30    1 : tunables  120   60    8 : slabdata      1      1      0
    inotify_event_cache    1    127     28  127    1 : tunables  120   60    8 : slabdata      1      1      0
    inotify_watch_cache   23     92     40   92    1 : tunables  120   60    8 : slabdata      1      1      0
    kioctx               135    135    256   15    1 : tunables  120   60    8 : slabdata      9      9      0
    kiocb                  0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    fasync_cache           0      0     16  203    1 : tunables  120   60    8 : slabdata      0      0      0
    shmem_inode_cache    553    585    436    9    1 : tunables   54   27    8 : slabdata     65     65      0
    posix_timers_cache     0      0     88   44    1 : tunables  120   60    8 : slabdata      0      0      0
    uid_cache              5     59     64   59    1 : tunables  120   60    8 : slabdata      1      1      0
    ip_mrt_cache           0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    tcp_bind_bucket       32    203     16  203    1 : tunables  120   60    8 : slabdata      1      1      0
    inet_peer_cache        1     59     64   59    1 : tunables  120   60    8 : slabdata      1      1      0
    secpath_cache          0      0     32  113    1 : tunables  120   60    8 : slabdata      0      0      0
    xfrm_dst_cache         0      0    384   10    1 : tunables   54   27    8 : slabdata      0      0      0
    ip_dst_cache           6     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    arp_cache              2     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    RAW                    2      7    512    7    1 : tunables   54   27    8 : slabdata      1      1      0
    UDP                    3      7    512    7    1 : tunables   54   27    8 : slabdata      1      1      0
    tw_sock_TCP            3     30    128   30    1 : tunables  120   60    8 : slabdata      1      1      0
    request_sock_TCP       4     30    128   30    1 : tunables  120   60    8 : slabdata      1      1      0
    TCP                   43     49   1152    7    2 : tunables   24   12    8 : slabdata      7      7      0
    blkdev_ioc             3    127     28  127    1 : tunables  120   60    8 : slabdata      1      1      0
    blkdev_queue          23     24    956    4    1 : tunables   54   27    8 : slabdata      6      6      0
    blkdev_requests      137    161    172   23    1 : tunables  120   60    8 : slabdata      7      7      0
    biovec-256             7      8   3072    2    2 : tunables   24   12    8 : slabdata      4      4      0
    biovec-128             7     10   1536    5    2 : tunables   24   12    8 : slabdata      2      2      0
    biovec-64              7     10    768    5    1 : tunables   54   27    8 : slabdata      2      2      0
    biovec-16              7     15    256   15    1 : tunables  120   60    8 : slabdata      1      1      0
    biovec-4               8     59     64   59    1 : tunables  120   60    8 : slabdata      1      1      0
    biovec-1             406    406     16  203    1 : tunables  120   60    8 : slabdata      2      2    300
    bio                  564    660    128   30    1 : tunables  120   60    8 : slabdata     21     22    204
    utrace_engine_cache    0      0     32  113    1 : tunables  120   60    8 : slabdata      0      0      0
    utrace_cache           0      0     32  113    1 : tunables  120   60    8 : slabdata      0      0      0
    sock_inode_cache     149    230    384   10    1 : tunables   54   27    8 : slabdata     23     23      0
    skbuff_fclone_cache   20     20    384   10    1 : tunables   54   27    8 : slabdata      2      2      0
    skbuff_head_cache     86    210    256   15    1 : tunables  120   60    8 : slabdata     14     14      0
    file_lock_cache       22     40     96   40    1 : tunables  120   60    8 : slabdata      1      1      0
    Acpi-Operand        1147   1196     40   92    1 : tunables  120   60    8 : slabdata     13     13      0
    Acpi-ParseExt          0      0     44   84    1 : tunables  120   60    8 : slabdata      0      0      0
    Acpi-Parse             0      0     28  127    1 : tunables  120   60    8 : slabdata      0      0      0
    Acpi-State             0      0     44   84    1 : tunables  120   60    8 : slabdata      0      0      0
    Acpi-Namespace       615    676     20  169    1 : tunables  120   60    8 : slabdata      4      4      0
    delayacct_cache      233    312     48   78    1 : tunables  120   60    8 : slabdata      4      4      0
    taskstats_cache       12     53     72   53    1 : tunables  120   60    8 : slabdata      1      1      0
    proc_inode_cache     622    693    356   11    1 : tunables   54   27    8 : slabdata     63     63      0
    sigqueue               8     27    144   27    1 : tunables  120   60    8 : slabdata      1      1      0
    radix_tree_node     6220   8134    276   14    1 : tunables   54   27    8 : slabdata    581    581      0
    bdev_cache            37     42    512    7    1 : tunables   54   27    8 : slabdata      6      6      0
    sysfs_dir_cache     4980   4992     48   78    1 : tunables  120   60    8 : slabdata     64     64      0
    mnt_cache             36     60    128   30    1 : tunables  120   60    8 : slabdata      2      2      0
    inode_cache         1113   1254    340   11    1 : tunables   54   27    8 : slabdata    114    114     81
    dentry_cache       11442  18560    136   29    1 : tunables  120   60    8 : slabdata    640    640    180
    filp                7607  10000    192   20    1 : tunables  120   60    8 : slabdata    500    500    120
    names_cache           19     19   4096    1    1 : tunables   24   12    8 : slabdata     19     19      0
    avc_node              14     72     52   72    1 : tunables  120   60    8 : slabdata      1      1      0
    selinux_inode_security 814   1170     48   78    1 : tunables  120   60    8 : slabdata     15     15      0
    key_jar               14     30    128   30    1 : tunables  120   60    8 : slabdata      1      1      0
    idr_layer_cache      170    203    136   29    1 : tunables  120   60    8 : slabdata      7      7      0
    buffer_head        38892  39024     52   72    1 : tunables  120   60    8 : slabdata    542    542      0
    mm_struct            108    135    448    9    1 : tunables   54   27    8 : slabdata     15     15      0
    vm_area_struct     11169  14904     84   46    1 : tunables  120   60    8 : slabdata    324    324    144
    fs_cache              82    177     64   59    1 : tunables  120   60    8 : slabdata      3      3      0
    files_cache          108    140    384   10    1 : tunables   54   27    8 : slabdata     14     14      0
    signal_cache         142    171    448    9    1 : tunables   54   27    8 : slabdata     19     19      0
    sighand_cache        127    135   1344    3    1 : tunables   24   12    8 : slabdata     45     45      0
    task_struct          184    246   1360    3    1 : tunables   24   12    8 : slabdata     82     82      0
    anon_vma            3313   5842     12  254    1 : tunables  120   60    8 : slabdata     23     23      0
    pgd                   84     84   4096    1    1 : tunables   24   12    8 : slabdata     84     84      0
    pid                  237    303     36  101    1 : tunables  120   60    8 : slabdata      3      3      0
    size-131072(DMA)       0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
    size-131072            0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
    size-65536(DMA)        0      0  65536    1   16 : tunables    8    4    0 : slabdata      0      0      0
    size-65536             2      2  65536    1   16 : tunables    8    4    0 : slabdata      2      2      0
    size-32768(DMA)        0      0  32768    1    8 : tunables    8    4    0 : slabdata      0      0      0
    size-32768             9      9  32768    1    8 : tunables    8    4    0 : slabdata      9      9      0
    size-16384(DMA)        0      0  16384    1    4 : tunables    8    4    0 : slabdata      0      0      0
    size-16384             6      6  16384    1    4 : tunables    8    4    0 : slabdata      6      6      0
    size-8192(DMA)         0      0   8192    1    2 : tunables    8    4    0 : slabdata      0      0      0
    size-8192              5      5   8192    1    2 : tunables    8    4    0 : slabdata      5      5      0
    size-4096(DMA)         0      0   4096    1    1 : tunables   24   12    8 : slabdata      0      0      0
    size-4096            205    205   4096    1    1 : tunables   24   12    8 : slabdata    205    205      0
    size-2048(DMA)         0      0   2048    2    1 : tunables   24   12    8 : slabdata      0      0      0
    size-2048            260    270   2048    2    1 : tunables   24   12    8 : slabdata    135    135      0
    size-1024(DMA)         0      0   1024    4    1 : tunables   54   27    8 : slabdata      0      0      0
    size-1024            204    204   1024    4    1 : tunables   54   27    8 : slabdata     51     51      0
    size-512(DMA)          0      0    512    8    1 : tunables   54   27    8 : slabdata      0      0      0
    size-512             367    464    512    8    1 : tunables   54   27    8 : slabdata     58     58      0
    size-256(DMA)          0      0    256   15    1 : tunables  120   60    8 : slabdata      0      0      0
    size-256             487    495    256   15    1 : tunables  120   60    8 : slabdata     33     33      0
    size-128(DMA)          0      0    128   30    1 : tunables  120   60    8 : slabdata      0      0      0
    size-128            2242   2490    128   30    1 : tunables  120   60    8 : slabdata     83     83      0
    size-64(DMA)           0      0     64   59    1 : tunables  120   60    8 : slabdata      0      0      0
    size-32(DMA)           0      0     32  113    1 : tunables  120   60    8 : slabdata      0      0      0
    size-64             1409   2950     64   59    1 : tunables  120   60    8 : slabdata     50     50      0
    size-32             3596   3842     32  113    1 : tunables  120   60    8 : slabdata     34     34      0
    kmem_cache           145    150    256   15    1 : tunables  120   60    8 : slabdata     10     10      0
    [root@localhost ~]# slabtop -d 5
    Active / Total Objects (% used)    : 97257 / 113249 (85.9%)
    Active / Total Slabs (% used)      : 4488 / 4488 (100.0%)
    Active / Total Caches (% used)     : 101 / 146 (69.2%)
    Active / Total Size (% used)       : 15076.34K / 17587.55K (85.7%)
    Minimum / Average / Maximum Object : 0.01K / 0.16K / 128.00K
      OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
    25776  25764  99%    0.05K    358       72      1432K buffer_head
    16146  15351  95%    0.08K    351       46      1404K vm_area_struct
    15138   7779  51%    0.13K    522       29      2088K dentry_cache
      9720   9106  93%    0.19K    486       20      1944K filp
      7714   7032  91%    0.27K    551       14      2204K radix_tree_node
      5070   5018  98%    0.05K     65       78       260K sysfs_dir_cache
      4826   4766  98%    0.01K     19      254        76K anon_vma
      4824   3406  70%    0.48K    603        8      2412K ext3_inode_cache
      3842   3691  96%    0.03K     34      113       136K size-32
      2190   2174  99%    0.12K     73       30       292K size-128
      1711   1364  79%    0.06K     29       59       116K size-64
      1210   1053  87%    0.33K    110       11       440K inode_cache
      1196   1147  95%    0.04K     13       92        52K Acpi-Operand
      1170    814  69%    0.05K     15       78        60K selinux_inode_security
       936    414  44%    0.05K     13       72        52K journal_head
       747    738  98%    0.43K     83        9       332K shmem_inode_cache
       693    617  89%    0.35K     63       11       252K proc_inode_cache
       676    615  90%    0.02K      4      169        16K Acpi-Namespace
       609    136  22%    0.02K      3      203        12K biovec-1
       495    493  99%    0.25K     33       15       132K size-256
       480    384  80%    0.12K     16       30        64K bio
       440    399  90%    0.50K     55        8       220K size-512
       312    206  66%    0.05K      4       78        16K delayacct_cache
       303    209  68%    0.04K      3      101        12K pid
       290    290 100%    0.38K     29       10       116K sock_inode_cache
    [root@localhost ~]# cat /etc/sysctl.conf
    # Kernel sysctl configuration file for Red Hat Linux
    # Controls IP packet forwarding
    net.ipv4.ip_forward=0
    # Controls source route verification
    net.ipv4.conf.default.rp_filter=1
    # Do not accept source routing
    net.ipv4.conf.default.accept_source_route=0
    # Oracle
    net.ipv4.ip_local_port_range=1024 65000
    net.core.rmem_default=4194304
    net.core.rmem_max=4194304
    net.core.wmem_default=262144
    net.core.wmem_max=262144
    net.ipv4.tcp_rmem=4096 65536 4194304
    net.ipv4.tcp_wmem=4096 65536 4194304
    # Keepalive Oracle
    net.ipv4.tcp_keepalive_time=3000
    net.ipv4.tcp_keepalive_intvl=30
    net.ipv4.tcp_keepalive_probes=15
    net.ipv4.tcp_retries2=3
    net.ipv4.tcp_syn_retries=2
    net.ipv4.tcp_sack=0
    net.ipv4.tcp_timestamps=0
    net.ipv4.tcp_window_scaling=0
    # Oracle
    fs.file-max = 6553600
    fs.aio-max-nr=3145728
    kernel.shmmni=4096
    kernel.sem=250 32000 100 142
    kernel.shmmax=2147483648
    kernel.shmall=3279547
    kernel.msgmnb=65536
    kernel.msgmni=2878
    kernel.msgmax=8192
    kernel.exec-shield=0
    # Controls the System Request debugging functionality of the kernel
    kernel.sysrq=1
    kernel.panic=60
    kernel.core_uses_pid=1
    [root@localhost ~]# free | grep Swap
    Swap:      3148700     319916    2828784
    [root@localhost ~]# cat /etc/fstab | grep "/dev/shm"
    tmpfs                   /dev/shm                tmpfs   size=1024M      0 0
    [root@localhost ~]# df | grep "/dev/shm"
    tmpfs                  1048576    452128    596448  44% /dev/shm
    NON-DEFAULT DB PARAMETERS:
    db_block_size        8192
    memory_target          633339904  /* automatic memory management */
    open_cursors         300
    processes            256
    disk_async_io        TRUE
    filesystemio_options SETALL

  • Queue consumer stops with 100% cpu usage

    I'm trying to use Berkeley DB queue with transactions. When I tested what happens when transactions with DB_APPEND are aborted I found that while it works and DB_CONSUME correctly skips over rolled back records, unfortunately extents that have those records are never deleted, which causes database to always grow. Next I tried DB_CONSUME with database opened using DB_INORDER flag and it seems there's a serious regression in Berkeley DB that causes it to loop indefinitely with 100% cpu usage when it encounters a rolled back record. I tested various versions and found that this bug doesn't happen with 5.1.29, but it is reproducible with 5.2.42, so this regression might have been introduced in 5.2. I have also tested 5.3 and 6.0, and both have this behavior. There may be something wrong with the way queue records are rolled back, one indication of that would be that in 5.1.29 doesn't have neither of the two problems I found with DB_QUEUE: extents are deleted after being consumed, and there are no issues when consuming with DB_INORDER either.
    You can find Python code to reproduce this issue here:
    https://gist.github.com/snaury/027a3c546f5b0a62a440
    Sorry for using Python and not e.g. C++, but it's a lot shorter that way.

    We have looked at the issues and they are valid.   We will roll the fixes out for this in our next release of BDB.   The test case was very useful and really helped to speed the process up.    If you have any questions, please contact me directly at [email protected]  Thanks again for bringing this to our attention.
    thanks
    mike

  • How to create a DB Adapter with select query having inner query

    Hi All,
    I am trying to create a DB Adapter with select query. The query has some inner queries in it. It is just like this select a, b, c, (select d from e) d, (select e from e) e from tablename.
    The problem here is with the xsd generated for this query. Xsd is not getting generated properly for all the fields it is just getting generated till c element and when it encounters
    the inner query it is stopping the generation of xsd. So for the above query the xsd is something similar to the below
    <xs:complexType name="rewOutput">
    <xs:sequence>
    <xs:element name="a" type="xs:string" nillable="true"/>
    <xs:element name="b" type="xs:string" nillable="true"/>
    <xs:element name="c" type="xs:string" nillable="true"/>
    <xs:element name="select_d" type="xs:string" nillable="true"/>
    </xs:sequence>
    </xs:complexType>
    as shown above the xsd is just getting generated till the first inner query. What should be done to get the full fledged xsd. Should it be manually built ?? Please help me on this.
    Thanks In Advance.
    Edited by: 959766 on Nov 30, 2012 1:20 AM

    Hi,
    I don't think the parser will be able to understand your query properly... I would try building the xsd manually...
    Cheers,
    Vlad

  • Finder and loginwindow use 100% cpu with 10.6.8

    I recently installed the patch to OS X 10.6.8 and now the finder is very unstable and uses 100% cpu and the loginwindow uses 100% cpu also.  Yes I have Parallels 6 on this machine but I already "un-checked" the "show windows applications in doc" option which is the recommended solution.  However, this did not fix the problem.  I do not know how to determine what actual process is causing this finder / loginwindow issue.  I very much appreciate if anyone has suggestion how to fix this problem. 
    This is on a mid-2011 MacBookPro.
    thank you.

    TBauer, I had the same problem with 10.6.8 using 100% of the CPU with Parallels 6 installed.  The following steps solved this problem for me:
    0.  Take a screen shot of your Dock if you wish to remember it as currently set
    1. Launch Activity Monitor and click on the CPU column so you can see Dock using the CPU
    2.  Move   ///Users/ ...  /Library/Preferences/com.apple.dock.plist to the trash
    3.  Click on Dock and click on Quit Process to stop the Dock
    OS X will then rebuild the default Dock
    4.  Put the items back in the Dock that you want
    That solved the problem for me yesterday morning.  I've launched Parallels 6 several times now and moved the machine from my work network to home and the 100% CPU problem hasn't returned.
    Hope that works for you, too!
    I don't think using the combo updater will solve the problem.  The problem appears to be a .plist that is generated with OS X 10.6.7 and earlier that contains icons of a larger than Apple documented size causes the CPU looping.  Rebuilding the dock.plist under OS X 10.6.8 appears to solve the problem.
    Parallels has issued a knowledge bulletin saying they are looking into the problem.  On their web site they have another approach involving moving the offending icon out of the dock to solve the problem.  I like my solution better but theirs works, too.

  • Problem:100 % cpu usage with tcp server dll

    Hello,
     I am trying to write a dll with labwindows/cvi that allows me to create a TCP Server. This dll is integrated in labview.I created this Dll with example provides by Labwindows/cvi(rtserver.dll).
    Description of my problem: when i execute this dll in a "While Loop" in labview,the TCp server wait a connection and 100% cpu usage occurs. However when a client is connect to the server,the CPU is normaly used because the program stop when he meets the timeout of the tcpread() function. I would like to know how i could limit CPU usage  when the server is awaiting a client in the labview "While loop".
    I know I could use a DELAY() to limit Cpu usage ,but I would like to know if there are any others solutions.
    thank you.

    i dont know your exact application, but i generally use Q to transfer data to TCP loop in my prgram it helps me in two ways.
    1. it automatically restricts the iteration when ther is no data (Less CPU Usage, Less Unnecessary Trafic)
    2. Q can eliminate problems arising due to non synchronization of loop
    Tushar Jambhekar
    [email protected]
    Jambhekar Automation Solutions
    LabVIEW Consultancy, LabVIEW Training
    Rent a LabVIEW Developer, My Blog

  • 100% CPU usage with XP Cooler from PCAlert4

         Any idea why I would be running 100% cpu usage when running XP Cooler from PCAlert4?  I noticed PC was sluggish when running it so CTRL+ALT+DEL and under performance is 100% CPU with 245MB Ram Usage. No other TSR's running - several application but under 10% CPU usage without PCAlert and XP Cooler.
         I was also wondering if anyone had any ideas on the video?  I have the K7N2G with 768MB DDR PC 2100 (3x256) XP2200+ 266FSB running 1804MHz - Maxtor 30GB 7200RPM - 350W PSU (raidmax - yea yea I know, dont say a word though LOL) on board video and here is the problem - graphics are great, but they get choppy - running NFS HotPursuit 2 at 32bit 800x600 (doesnt seem to matter even when running 16bit 640x480still does it.) what setting am I missing?  Thanks in advance.

    Deathstalker (Richard),
         I did what you suggest in memory management and also changed out the mem on the board - it did make a difference, not as much as I had hoped, but it did.
    Raven,
         I have used Fraps in the past, forgot about it, but went ahead and downloaded it to get a better look.
    To the Both of you,
         Thanks so much for your replies, sometimes it just takes someone outside looking in to see the things overlooked.  But I went ahead and also ran all of the latest updates for the board (semi new system and I only installed with the CD that came with the Mobo) and everything is running better than expected.  Thanks again for your thoughts - keep 'em flowin, it's amazing whom we could help.  Take care.
    Don

  • Strange behavior in inner query with group by clause

    Hi All,
    I found a very strange behaviour with Inner query having a group by clause.
    Please look the sample code
    Select b,c,qty from (select a,b,c,sum(d) qty from tab_xyz group by b,c);
    This query gives output by summing b,c wise. But when i run the inner query it gives error as "not a group by expression "
    My question is - though the inner query is wrong, how is it possible that this query gives output.
    it behaves like -
    Select b,c,qty from (select b,c,sum(d) qty from tab_xyz group by b,c);
    Is it a normal behaviour ?
    If it is a normal behaviour, then how group by behaves inside a inner query.
    Thanks !!

    This case I have tested already and it throws error.
    But why the initial posted query is not throwing
    error even the inner query is wrong.
    In what way oracle behaves for the initial posted
    query?what is the scenario that throws the error? is it at the time when you only run the inner query or the whole query?

  • 100% CPU usage with plasma

    Hi!
    Since the last update to KDE 4.2.2 plasma causes all of the PCs that run with Archlinux and KDE to raise my CPU usage to 100%.
    It's always caused by plasma and did not happen before with version 4.2.1
    Does anyone have the same experience? How can I fix this?
    It's very annoying especially on the Laptops and Netbooks I'm running with KDE....
    Or should I file a bug report or am I the only one experiencing this?

    Sorry for the thread necromancy, but I have the same problem.
    At first there was no problems. I had installed kdemod to test it after spending long time with fluxbox and gtk apps. At that time there were no problems. For whatever reason I decided to reinstall Arch and put only KDEmod on it.
    Hellooo plasma hogging the cpu. I have no calendar plasmoid. I have no plasmoids on the desktop at all. There are couple of them on the taskbar:
    kmenu (or whatever it is called), stasks, systray, pager, digital clock.
    The digital clock has a calendar when I click it. Testing with no digital clock plasmoid right now.
    A full clean reinstall of kde mod didn't help, either. Did anyone found the source of the hogging?

  • Xcode using 100% cpu even with no projects open:  Solution

    Symptom:
    I had a very strange problem with Xcode 3.2.1 on Snow Leopard 10.6.2. As soon as I opened a project, Xcode would start using 100% of the cpu. It would continue doing this even after I closed ALL open projects. Xcode was using 100% cpu (200% actually) even while idle! Xcode would also often hang. I tried deleting Xcode and reinstalling twice. That didn't help. After much searching and trial and error I discovered the problem and the solution:
    Problem:
    I had an SCM entry defined from a previous remote site session in the SCM tab of the Xcode preferences. This site was no longer responding to requests, and apparently Xcode was continually trying to connect. Apparently the preferences were saved across the uninstall even though I used the shell script to uninstall all the developer tools.
    Solution:
    Delete the unavailable repository from the SCM tab in Xcode preferences.
    I hope this saves someone the aggravation this problem has caused me.
    David Maynard

    Post to the developer forums under OS X Technologies.

  • Safari loads 100% CPU while opening a webpage when working in cooperation with DeviceLock

    I have Safari 5.0.5 and DeviceLock 7.1 installed on same computer running Windows XP x86.
    When I confugure any network protocol settings in Devicelock (to make its network module active), Safari loads 100% CPU while opening any webpage, for example http://www.apple.com/startpage/
    This issue doesn't occurs on other browsers - Internet Explorer, Firefox, so I assume the issue belongs to Safari, not to DeviceLock.

    It may not be DeviceLock, or Windows. I see (via Activity Monitor) Safari use 100% CPU while loading a new page on my G5 iMac. Then it drops back again. It may be something to do with Safari 5.0.5

  • 100% CPU after connecting with RDP

    Hi,
    We have a W2K3 SP2 vmware guest server running in our network. It's a member server. It has only Lotus domino installed.
    But since last week that after connecting via RDP  (doesn't matter to connect to console or any session) or with vwware console that the server CPU peaks 100% and don't allow connecting nor working with  it.
    We have to force shutdown from ESXi host.
    Does anybody know what could be the cause.
    Thanks,

    Hi,
    You may need to use Task Manager, Resource Monitor or Process Explorer to check which process causes 100% CPU usage.
    Thanks.
    Jeremy Wu
    TechNet Community Support

Maybe you are looking for