SHUTDOWN: Active sessions prevent database close operation

Hi
Yesterday morning, our Oracle Apps Database did not shutdown and throws the following error.
Fri May 11 06:57:18 2012
Active call for process 2031784 user 'xxxl' program 'oracleyyy@zzz'
SHUTDOWN: waiting for active calls to complete.
Fri May 11 07:04:01 2012
Incremental checkpoint up to RBA [0x165b.1b2b21.0], current log tail at RBA [0x165b.1b2b21.0]
Fri May 11 07:11:14 2012
MMNL absent for 1203 secs; Foregrounds taking over
Fri May 11 07:24:05 2012
Incremental checkpoint up to RBA [0x165b.1b2b42.0], current log tail at RBA [0x165b.1b2b4a.0]
Fri May 11 07:44:10 2012
Incremental checkpoint up to RBA [0x165b.1b2b6f.0], current log tail at RBA [0x165b.1b2b7d.0]
Fri May 11 07:52:18 2012
SHUTDOWN: Active sessions prevent database close operation
Fri May 11 08:04:39 2012
Since last 3 years, we never faced such a situation even though many modules (oracle Apps) were implemented from time to time. This time OTL module is going live and consultants were running some procedure during backup start time.
Even after issuing 'addbctl.sh stop immediate', how come oracle did not close all the database sessions? How to prevent such situation in future?
Any help is highly appreciated.
Regards
Arizuddin

you can first do a alter system checkpoint and then try to shutdown the database.
You can also kill all the active user sessions from v$session and then shutdown the database.

Similar Messages

  • Running of process flow does not show any Active session in Database

    Hi Team,
    I am running a process flow in OWB 11g ( From Design Center ) which is having around 100 maps within it. However, from Control Center I can see the Process Flow is running ( i.e. Green check is visible beside the process flow) but when I run SQL query in backend database ; I am unable to see any running object ( i.e. OWB map name as package object) there corresponding to this Process Flow
    I am running the below query to check the availability of running session :-
    SELECT A.LOGON_TIME,A.SID,B.OBJECT_NAME,A.*
    FROM gv$session A, dba_objects B
    WHERE A.PLSQL_ENTRY_OBJECT_ID = B.OBJECT_ID
    AND A.STATUS = 'ACTIVE'
    Could you please suggest if this is something wrong in the development of the Process Flow or we can`t see any running map there in backend when we execute any process flow from OWB ?
    Thanks in advance
    Nilava Sen

    Try below query
    select sid,module,program,status,sql_id from gv$session where status='ACTIVE';
    select * from gv$access;

  • ACTIVE PROCESS PREVENTS SHUTDOWN OPERATION IN ALERT LOG

    Shutdown immediate seems to be hanged for few hours.............
    Alert log said that...........
    ACTIVE PROCESS PREVENTS SHUTDOWN OPERATION ..........
    Extract of alert_log:
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 11:52:59 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 11:58:00 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 12:03:01 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 12:08:03 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 12:13:04 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 12:18:05 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 12:23:07 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 12:28:08 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thu Aug 12 12:33:09 2010
    SHUTDOWN: Active processes prevent shutdown operation
    Thanks in advance.......
    Regards,
    New2DBA

    Connect sqlplus "/as sysdba" then shutdown abort Refer below metalink doc
    *Getting Shutdown: Active Processes Prevent Shutdown Operation [ID 780167.1]*

  • Active session Spike on Oracle RAC 11G R2 on HP UX

    Dear Experts,
    We need urgent help please, as we are facing very low performance in production database.
    We are having oracle 11G RAC on HP Unix environment. Following is the ADDM report. Kindly check and please help me to figure it out the issue and resolve it at earliest.
    ---------Instance 1---------------
              ADDM Report for Task 'TASK_36650'
    Analysis Period
    AWR snapshot range from 11634 to 11636.
    Time period starts at 21-JUL-13 07.00.03 PM
    Time period ends at 21-JUL-13 09.00.49 PM
    Analysis Target
    Database 'MCMSDRAC' with DB ID 2894940361.
    Database version 11.2.0.1.0.
    ADDM performed an analysis of instance mcmsdrac1, numbered 1 and hosted at
    mcmsdbl1.
    Activity During the Analysis Period
    Total database time was 38466 seconds.
    The average number of active sessions was 5.31.
    Summary of Findings
       Description           Active Sessions      Recommendations
                             Percent of Activity  
    1  CPU Usage             1.44 | 27.08         1
    2  Interconnect Latency  .07 | 1.33           1
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Findings and Recommendations
    Finding 1: CPU Usage
    Impact is 1.44 active sessions, 27.08% of total activity.
    Host CPU was a bottleneck and the instance was consuming 99% of the host CPU.
    All wait times will be inflated by wait for CPU.
    Host CPU consumption was 99%.
       Recommendation 1: Host Configuration
       Estimated benefit is 1.44 active sessions, 27.08% of total activity.
       Action
          Consider adding more CPUs to the host or adding instances serving the
          database on other hosts.
       Action
          Session CPU consumption was throttled by the Oracle Resource Manager.
          Consider revising the resource plan that was active during the analysis
          period.
    Finding 2: Interconnect Latency
    Impact is .07 active sessions, 1.33% of total activity.
    Higher than expected latency of the cluster interconnect was responsible for
    significant database time on this instance.
    The instance was consuming 110 kilo bits per second of interconnect bandwidth.
    20% of this interconnect bandwidth was used for global cache messaging, 21%
    for parallel query messaging and 7% for database lock management.
    The average latency for 8K interconnect messages was 42153 microseconds.
    The instance is using the private interconnect device "lan2" with IP address
    172.16.200.71 and source "Oracle Cluster Repository".
    The device "lan2" was used for 100% of interconnect traffic and experienced 0
    send or receive errors during the analysis period.
       Recommendation 1: Host Configuration
       Estimated benefit is .07 active sessions, 1.33% of total activity.
       Action
          Investigate cause of high network interconnect latency between database
          instances. Oracle's recommended solution is to use a high speed
          dedicated network.
       Action
          Check the configuration of the cluster interconnect. Check OS setup like
          adapter setting, firmware and driver release. Check that the OS's socket
          receive buffers are large enough to store an entire multiblock read. The
          value of parameter "db_file_multiblock_read_count" may be decreased as a
          workaround.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Additional Information
    Miscellaneous Information
    Wait class "Application" was not consuming significant database time.
    Wait class "Cluster" was not consuming significant database time.
    Wait class "Commit" was not consuming significant database time.
    Wait class "Concurrency" was not consuming significant database time.
    Wait class "Configuration" was not consuming significant database time.
    Wait class "Network" was not consuming significant database time.
    Wait class "User I/O" was not consuming significant database time.
    Session connect and disconnect calls were not consuming significant database
    time.
    Hard parsing of SQL statements was not consuming significant database time.
    The database's maintenance windows were active during 100% of the analysis
    period.
    ----------------Instance 2 --------------------
              ADDM Report for Task 'TASK_36652'
    Analysis Period
    AWR snapshot range from 11634 to 11636.
    Time period starts at 21-JUL-13 07.00.03 PM
    Time period ends at 21-JUL-13 09.00.49 PM
    Analysis Target
    Database 'MCMSDRAC' with DB ID 2894940361.
    Database version 11.2.0.1.0.
    ADDM performed an analysis of instance mcmsdrac2, numbered 2 and hosted at
    mcmsdbl2.
    Activity During the Analysis Period
    Total database time was 2898 seconds.
    The average number of active sessions was .4.
    Summary of Findings
        Description                 Active Sessions      Recommendations
                                    Percent of Activity  
    1   Top SQL Statements          .11 | 27.65          5
    2   Interconnect Latency        .1 | 24.15           1
    3   Shared Pool Latches         .09 | 22.42          1
    4   PL/SQL Execution            .06 | 14.39          2
    5   Unusual "Other" Wait Event  .03 | 8.73           4
    6   Unusual "Other" Wait Event  .03 | 6.42           3
    7   Unusual "Other" Wait Event  .03 | 6.29           6
    8   Hard Parse                  .02 | 5.5            0
    9   Soft Parse                  .02 | 3.86           2
    10  Unusual "Other" Wait Event  .01 | 3.75           4
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Findings and Recommendations
    Finding 1: Top SQL Statements
    Impact is .11 active sessions, 27.65% of total activity.
    SQL statements consuming significant database time were found. These
    statements offer a good opportunity for performance improvement.
       Recommendation 1: SQL Tuning
       Estimated benefit is .05 active sessions, 12.88% of total activity.
       Action
          Investigate the PL/SQL statement with SQL_ID "d1s02myktu19h" for
          possible performance improvements. You can supplement the information
          given here with an ASH report for this SQL_ID.
          Related Object
             SQL statement with SQL_ID d1s02myktu19h.
             begin dbms_utility.validate(:1,:2,:3,:4); end;
       Rationale
          The SQL Tuning Advisor cannot operate on PL/SQL statements.
       Rationale
          Database time for this SQL was divided as follows: 13% for SQL
          execution, 2% for parsing, 85% for PL/SQL execution and 0% for Java
          execution.
       Rationale
          SQL statement with SQL_ID "d1s02myktu19h" was executed 48 times and had
          an average elapsed time of 7 seconds.
       Rationale
          Waiting for event "library cache pin" in wait class "Concurrency"
          accounted for 70% of the database time spent in processing the SQL
          statement with SQL_ID "d1s02myktu19h".
       Rationale
          Top level calls to execute the PL/SQL statement with SQL_ID
          "63wt8yna5umd6" are responsible for 100% of the database time spent on
          the PL/SQL statement with SQL_ID "d1s02myktu19h".
          Related Object
             SQL statement with SQL_ID 63wt8yna5umd6.
             begin DBMS_UTILITY.COMPILE_SCHEMA( 'TPAUSER', FALSE ); end;
       Recommendation 2: SQL Tuning
       Estimated benefit is .02 active sessions, 4.55% of total activity.
       Action
          Run SQL Tuning Advisor on the SELECT statement with SQL_ID
          "fk3bh3t41101x".
          Related Object
             SQL statement with SQL_ID fk3bh3t41101x.
             SELECT MEM.MEMBER_CODE ,MEM.E_NAME,Pol.Policy_no
             ,pol.date_from,pol.date_to,POL.E_NAME,MEM.SEX,(SYSDATE-MEM.BIRTH_DATE
             ) AGE,POL.SCHEME_NO FROM TPAUSER.MEMBERS MEM,TPAUSER.POLICY POL WHERE
             POL.QUOTATION_NO=MEM.QUOTATION_NO AND POL.BRANCH_CODE=MEM.BRANCH_CODE
             and endt_no=(select max(endt_no) from tpauser.members mm where
             mm.member_code=mem.member_code AND mm.QUOTATION_NO=MEM.QUOTATION_NO)
             and member_code like '%' || nvl(:1,null) ||'%' ORDER BY MEMBER_CODE
       Rationale
          The SQL spent 92% of its database time on CPU, I/O and Cluster waits.
          This part of database time may be improved by the SQL Tuning Advisor.
       Rationale
          Database time for this SQL was divided as follows: 100% for SQL
          execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
          execution.
       Rationale
          SQL statement with SQL_ID "fk3bh3t41101x" was executed 14 times and had
          an average elapsed time of 4.9 seconds.
       Rationale
          At least one execution of the statement ran in parallel.
       Recommendation 3: SQL Tuning
       Estimated benefit is .02 active sessions, 3.79% of total activity.
       Action
          Run SQL Tuning Advisor on the SELECT statement with SQL_ID
          "7mhjbjg9ntqf5".
          Related Object
             SQL statement with SQL_ID 7mhjbjg9ntqf5.
             SELECT SUM(CNT) FROM (SELECT COUNT(PROC_CODE) CNT FROM
             TPAUSER.TORBINY_PROCEDURE WHERE BRANCH_CODE = :B6 AND QUOTATION_NO =
             :B5 AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND PR_EFFECTIVE_DATE<=
             :B2 AND PROC_CODE = :B1 UNION SELECT COUNT(MED_CODE) CNT FROM
             TPAUSER.TORBINY_MEDICINE WHERE BRANCH_CODE = :B6 AND QUOTATION_NO =
             :B5 AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND M_EFFECTIVE_DATE<= :B2
             AND MED_CODE = :B1 UNION SELECT COUNT(LAB_CODE) CNT FROM
             TPAUSER.TORBINY_LAB WHERE BRANCH_CODE = :B6 AND QUOTATION_NO = :B5
             AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND L_EFFECTIVE_DATE<= :B2 AND
             LAB_CODE = :B1 )
       Rationale
          The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
          This part of database time may be improved by the SQL Tuning Advisor.
       Rationale
          Database time for this SQL was divided as follows: 0% for SQL execution,
          0% for parsing, 100% for PL/SQL execution and 0% for Java execution.
       Rationale
          SQL statement with SQL_ID "7mhjbjg9ntqf5" was executed 31 times and had
          an average elapsed time of 3.4 seconds.
       Rationale
          Top level calls to execute the SELECT statement with SQL_ID
          "a11nzdnd91gsg" are responsible for 100% of the database time spent on
          the SELECT statement with SQL_ID "7mhjbjg9ntqf5".
          Related Object
             SQL statement with SQL_ID a11nzdnd91gsg.
             SELECT POLICY_NO,SCHEME_NO FROM TPAUSER.POLICY WHERE QUOTATION_NO
             =:B1
       Recommendation 4: SQL Tuning
       Estimated benefit is .01 active sessions, 3.03% of total activity.
       Action
          Investigate the SELECT statement with SQL_ID "4uqs4jt7aca5s" for
          possible performance improvements. You can supplement the information
          given here with an ASH report for this SQL_ID.
          Related Object
             SQL statement with SQL_ID 4uqs4jt7aca5s.
             SELECT DISTINCT USER_ID FROM GV$SESSION, USERS WHERE UPPER (USERNAME)
             = UPPER (USER_ID) AND USERS.APPROVAL_CLAIM='VC' AND USER_ID=:B1
       Rationale
          The SQL spent only 0% of its database time on CPU, I/O and Cluster
          waits. Therefore, the SQL Tuning Advisor is not applicable in this case.
          Look at performance data for the SQL to find potential improvements.
       Rationale
          Database time for this SQL was divided as follows: 100% for SQL
          execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
          execution.
       Rationale
          SQL statement with SQL_ID "4uqs4jt7aca5s" was executed 261 times and had
          an average elapsed time of 0.35 seconds.
       Rationale
          At least one execution of the statement ran in parallel.
       Rationale
          Top level calls to execute the PL/SQL statement with SQL_ID
          "91vt043t78460" are responsible for 100% of the database time spent on
          the SELECT statement with SQL_ID "4uqs4jt7aca5s".
          Related Object
             SQL statement with SQL_ID 91vt043t78460.
             begin TPAUSER.RECEIVE_NEW_FAX_APRROVAL(:V00001,:V00002,:V00003,:V0000
             4); end;
       Recommendation 5: SQL Tuning
       Estimated benefit is .01 active sessions, 3.03% of total activity.
       Action
          Run SQL Tuning Advisor on the SELECT statement with SQL_ID
          "7kt28fkc0yn5f".
          Related Object
             SQL statement with SQL_ID 7kt28fkc0yn5f.
             SELECT COUNT(*) FROM TPAUSER.APPROVAL_MASTER WHERE APPROVAL_STATUS IS
             NULL AND (UPPER(CODED) = UPPER(:B1 ) OR UPPER(PROCESSED_BY) =
             UPPER(:B1 ))
       Rationale
          The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
          This part of database time may be improved by the SQL Tuning Advisor.
       Rationale
          Database time for this SQL was divided as follows: 100% for SQL
          execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
          execution.
       Rationale
          SQL statement with SQL_ID "7kt28fkc0yn5f" was executed 1034 times and
          had an average elapsed time of 0.063 seconds.
       Rationale
          Top level calls to execute the PL/SQL statement with SQL_ID
          "91vt043t78460" are responsible for 100% of the database time spent on
          the SELECT statement with SQL_ID "7kt28fkc0yn5f".
          Related Object
             SQL statement with SQL_ID 91vt043t78460.
             begin TPAUSER.RECEIVE_NEW_FAX_APRROVAL(:V00001,:V00002,:V00003,:V0000
             4); end;
    Finding 2: Interconnect Latency
    Impact is .1 active sessions, 24.15% of total activity.
    Higher than expected latency of the cluster interconnect was responsible for
    significant database time on this instance.
    The instance was consuming 128 kilo bits per second of interconnect bandwidth.
    17% of this interconnect bandwidth was used for global cache messaging, 6% for
    parallel query messaging and 8% for database lock management.
    The average latency for 8K interconnect messages was 41863 microseconds.
    The instance is using the private interconnect device "lan2" with IP address
    172.16.200.72 and source "Oracle Cluster Repository".
    The device "lan2" was used for 100% of interconnect traffic and experienced 0
    send or receive errors during the analysis period.
       Recommendation 1: Host Configuration
       Estimated benefit is .1 active sessions, 24.15% of total activity.
       Action
          Investigate cause of high network interconnect latency between database
          instances. Oracle's recommended solution is to use a high speed
          dedicated network.
       Action
          Check the configuration of the cluster interconnect. Check OS setup like
          adapter setting, firmware and driver release. Check that the OS's socket
          receive buffers are large enough to store an entire multiblock read. The
          value of parameter "db_file_multiblock_read_count" may be decreased as a
          workaround.
       Symptoms That Led to the Finding:
          Inter-instance messaging was consuming significant database time on this
          instance.
          Impact is .06 active sessions, 14.23% of total activity.
             Wait class "Cluster" was consuming significant database time.
             Impact is .06 active sessions, 14.23% of total activity.
    Finding 3: Shared Pool Latches
    Impact is .09 active sessions, 22.42% of total activity.
    Contention for latches related to the shared pool was consuming significant
    database time.
    Waits for "library cache lock" amounted to 5% of database time.
    Waits for "library cache pin" amounted to 17% of database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .09 active sessions, 22.42% of total activity.
       Action
          Investigate the cause for latch contention using the given blocking
          sessions or modules.
       Rationale
          The session with ID 17 and serial number 15595 in instance number 1 was
          the blocking session responsible for 34% of this recommendation's
          benefit.
       Symptoms That Led to the Finding:
          Wait class "Concurrency" was consuming significant database time.
          Impact is .1 active sessions, 24.96% of total activity.
    Finding 4: PL/SQL Execution
    Impact is .06 active sessions, 14.39% of total activity.
    PL/SQL execution consumed significant database time.
       Recommendation 1: SQL Tuning
       Estimated benefit is .05 active sessions, 12.5% of total activity.
       Action
          Tune the entry point PL/SQL "SYS.DBMS_UTILITY.COMPILE_SCHEMA" of type
          "PACKAGE" and ID 6019. Refer to the PL/SQL documentation for addition
          information.
       Rationale
          318 seconds spent in executing PL/SQL "SYS.DBMS_UTILITY.VALIDATE#2" of
          type "PACKAGE" and ID 6019.
       Recommendation 2: SQL Tuning
       Estimated benefit is .01 active sessions, 1.89% of total activity.
       Action
          Tune the entry point PL/SQL
          "SYSMAN.EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS" of type "PACKAGE" and
          ID 68654. Refer to the PL/SQL documentation for addition information.
    Finding 5: Unusual "Other" Wait Event
    Impact is .03 active sessions, 8.73% of total activity.
    Wait event "DFS lock handle" in wait class "Other" was consuming significant
    database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .03 active sessions, 8.73% of total activity.
       Action
          Investigate the cause for high "DFS lock handle" waits. Refer to
          Oracle's "Database Reference" for the description of this wait event.
       Recommendation 2: Application Analysis
       Estimated benefit is .03 active sessions, 8.27% of total activity.
       Action
          Investigate the cause for high "DFS lock handle" waits in Service
          "mcmsdrac".
       Recommendation 3: Application Analysis
       Estimated benefit is .02 active sessions, 5.05% of total activity.
       Action
          Investigate the cause for high "DFS lock handle" waits in Module "TOAD
          9.7.2.5".
       Recommendation 4: Application Analysis
       Estimated benefit is .01 active sessions, 3.21% of total activity.
       Action
          Investigate the cause for high "DFS lock handle" waits in Module
          "toad.exe".
       Symptoms That Led to the Finding:
          Wait class "Other" was consuming significant database time.
          Impact is .15 active sessions, 38.29% of total activity.
    Finding 6: Unusual "Other" Wait Event
    Impact is .03 active sessions, 6.42% of total activity.
    Wait event "reliable message" in wait class "Other" was consuming significant
    database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .03 active sessions, 6.42% of total activity.
       Action
          Investigate the cause for high "reliable message" waits. Refer to
          Oracle's "Database Reference" for the description of this wait event.
       Recommendation 2: Application Analysis
       Estimated benefit is .03 active sessions, 6.42% of total activity.
       Action
          Investigate the cause for high "reliable message" waits in Service
          "mcmsdrac".
       Recommendation 3: Application Analysis
       Estimated benefit is .02 active sessions, 4.13% of total activity.
       Action
          Investigate the cause for high "reliable message" waits in Module "TOAD
          9.7.2.5".
       Symptoms That Led to the Finding:
          Wait class "Other" was consuming significant database time.
          Impact is .15 active sessions, 38.29% of total activity.
    Finding 7: Unusual "Other" Wait Event
    Impact is .03 active sessions, 6.29% of total activity.
    Wait event "enq: PS - contention" in wait class "Other" was consuming
    significant database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .03 active sessions, 6.29% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits. Refer to
          Oracle's "Database Reference" for the description of this wait event.
       Recommendation 2: Application Analysis
       Estimated benefit is .02 active sessions, 6.02% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits in Service
          "mcmsdrac".
       Recommendation 3: Application Analysis
       Estimated benefit is .02 active sessions, 4.93% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits with
          P1,P2,P3 ("name|mode, instance, slave ID") values "1347616774", "1" and
          "3599" respectively.
       Recommendation 4: Application Analysis
       Estimated benefit is .01 active sessions, 2.74% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits in Module
          "Inbox Reader_92.exe".
       Recommendation 5: Application Analysis
       Estimated benefit is .01 active sessions, 2.74% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits in Module
          "TOAD 9.7.2.5".
       Recommendation 6: Application Analysis
       Estimated benefit is .01 active sessions, 1.37% of total activity.
       Action
          Investigate the cause for high "enq: PS - contention" waits with
          P1,P2,P3 ("name|mode, instance, slave ID") values "1347616774", "1" and
          "3598" respectively.
       Symptoms That Led to the Finding:
          Wait class "Other" was consuming significant database time.
          Impact is .15 active sessions, 38.29% of total activity.
    Finding 8: Hard Parse
    Impact is .02 active sessions, 5.5% of total activity.
    Hard parsing of SQL statements was consuming significant database time.
    Hard parses due to cursor environment mismatch were not consuming significant
    database time.
    Hard parsing SQL statements that encountered parse errors was not consuming
    significant database time.
    Hard parses due to literal usage and cursor invalidation were not consuming
    significant database time.
    The Oracle instance memory (SGA and PGA) was adequately sized.
       No recommendations are available.
       Symptoms That Led to the Finding:
          Contention for latches related to the shared pool was consuming
          significant database time.
          Impact is .09 active sessions, 22.42% of total activity.
             Wait class "Concurrency" was consuming significant database time.
             Impact is .1 active sessions, 24.96% of total activity.
    Finding 9: Soft Parse
    Impact is .02 active sessions, 3.86% of total activity.
    Soft parsing of SQL statements was consuming significant database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .02 active sessions, 3.86% of total activity.
       Action
          Investigate application logic to keep open the frequently used cursors.
          Note that cursors are closed by both cursor close calls and session
          disconnects.
       Recommendation 2: Database Configuration
       Estimated benefit is .02 active sessions, 3.86% of total activity.
       Action
          Consider increasing the session cursor cache size by increasing the
          value of parameter "session_cached_cursors".
       Rationale
          The value of parameter "session_cached_cursors" was "100" during the
          analysis period.
       Symptoms That Led to the Finding:
          Contention for latches related to the shared pool was consuming
          significant database time.
          Impact is .09 active sessions, 22.42% of total activity.
             Wait class "Concurrency" was consuming significant database time.
             Impact is .1 active sessions, 24.96% of total activity.
    Finding 10: Unusual "Other" Wait Event
    Impact is .01 active sessions, 3.75% of total activity.
    Wait event "IPC send completion sync" in wait class "Other" was consuming
    significant database time.
       Recommendation 1: Application Analysis
       Estimated benefit is .01 active sessions, 3.75% of total activity.
       Action
          Investigate the cause for high "IPC send completion sync" waits. Refer
          to Oracle's "Database Reference" for the description of this wait event.
       Recommendation 2: Application Analysis
       Estimated benefit is .01 active sessions, 3.75% of total activity.
       Action
          Investigate the cause for high "IPC send completion sync" waits with P1
          ("send count") value "1".
       Recommendation 3: Application Analysis
       Estimated benefit is .01 active sessions, 2.59% of total activity.
       Action
          Investigate the cause for high "IPC send completion sync" waits in
          Service "mcmsdrac".
       Recommendation 4: Application Analysis
       Estimated benefit is .01 active sessions, 1.73% of total activity.
       Action
          Investigate the cause for high "IPC send completion sync" waits in
          Module "TOAD 9.7.2.5".
       Symptoms That Led to the Finding:
          Wait class "Other" was consuming significant database time.
          Impact is .15 active sessions, 38.29% of total activity.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              Additional Information
    Miscellaneous Information
    Wait class "Application" was not consuming significant database time.
    Wait class "Commit" was not consuming significant database time.
    Wait class "Configuration" was not consuming significant database time.
    CPU was not a bottleneck for the instance.
    Wait class "Network" was not consuming significant database time.
    Wait class "User I/O" was not consuming significant database time.
    Session connect and disconnect calls were not consuming significant database
    time.
    The database's maintenance windows were active during 100% of the analysis
    period.
    Please help.

    Hello experts...
    Please do the needful... It's really very urgent.
    Thanks,
    Syed

  • ORA-1109 signalled during: alter database close

    Hi
    i have found the following error in alert log after i shut down my database for cold backup
    alter database close
    ORA-1109 signalled during: alter database close...
    Please advice is there any threat because of this error and whats the reason for the occurence of this error.
    Version of DB: 10.2.0.4.0
    I have DR configured for this db also..
    Regards,
    Arun Kumar

    Thats not the command i am using..
    I just use shutdown immediate.. when i use that command i get the sequnce of steps logged in alert log..
    there i find the error.. see below..(a part of alert log content)
    Shutting down instance: further logons disabled
    Sun Aug  9 19:12:39 2009
    Stopping background process CJQ0
    Sun Aug  9 19:12:39 2009
    Stopping background process MMNL
    Sun Aug  9 19:12:40 2009
    Stopping background process MMON
    Sun Aug  9 19:12:41 2009
    Shutting down instance (immediate)
    License high water mark = 5
    Sun Aug  9 19:12:41 2009
    Stopping Job queue slave processes, flags = 7
    Sun Aug  9 19:12:41 2009
    Job queue slave processes stopped
    Sun Aug  9 19:12:41 2009
    alter database close
    ORA-1109 signalled during: alter database close...*
    Sun Aug  9 19:12:41 2009
    alter database dismount
    Completed: alter database dismount
    ARCH: Archival disabled due to shutdown: 1089
    Shutting down archive processes
    Archiving is disabled
    Archive process shutdown avoided: 0 active
    ARCH: Archival disabled due to shutdown: 1089
    Shutting down archive processes

  • Active session count of an user

    Hi,
    Could you help me understand the concept of active user session count and the factors influencing the active sesssion count of an user
    1) Does running multiple queries in a number of query windows in SQL developer lead to increase active session count?
    2) Does a high degree of parallel option ( e.g. Parallel (Degree 8)) provided in a query lead to a higher session count?
    3) Does the size of data processed in a query influence session count?
    4) Does the complexity of a query influence session count?
    5) Can a session remain active even after completion of a query and thereby increase the active sessioncount?
    Regards
    -Learnsequel

    910874 wrote:
    Could you help me understand the concept of active user session count and the factors influencing the active sesssion count of an userThat depends on the client. Does the client use some form of multi-threading? If so, the client needs a separate and active Oracle session servicing each of its running threads.
    The user may only initiate a single connection to the database - but the application remembers the authentication and connection details and can transparently establish multiple additional sessions. (a common behaviour by TOAD and SQL-Developer)
    1) Does running multiple queries in a number of query windows in SQL developer lead to increase active session count?Yes - as an Oracle session is serialised. It can only execute a single client request at a time. Thus if the client has 3 windows/tabs with each running a SQL query - then 3 Oracle sessions are required to service that client.
    2) Does a high degree of parallel option ( e.g. Parallel (Degree 8)) provided in a query lead to a higher session count?No. PX slave processes are database processes. They only "assist" a session at specific times. Then they can "assist" other sessions with other parallel query processing. The database has a configurable PQ processing pool of processes. You can specify the minimum number of processes to create in the pool at startup. You can specify the ceiling of the pool.
    So no number of sessions can grow the number of PQ processes beyond the maximum size of the pool. And the pool is there to service all sessions. Not just a single session.
    3) Does the size of data processed in a query influence session count?No.
    4) Does the complexity of a query influence session count?No.
    5) Can a session remain active even after completion of a query and thereby increase the active sessioncount?This is default behaviour. If that session terminates, the client looses its database connection.
    In the case of a multi-threaded client, it can decide to close one or more of the transparent "background" sessions it created to the database, when no longer needing such a session. However, it will keep its initial (first) session open as its primary connection to the database.

  • Active Sessions unavailable

    I'm using oracle10g Enterprise Manager. Today I cannot see that pie-chart depicting the active sessions at the start page. There's also written:
    Active Sessions: Unavailable.
    When I click the Unavailable link, I can still see the Top sessions, etc.. The database is functioning in the normal way.
    Has someone ever came across this? I have seen this happening one day but i remember that it was solved on the next login. I tried to reboot the instance but in vain..

    Thanks DBMS_direct for your reply,
    I try to upgrade repository by using following cmd.
    # emca -upgrade db -cluster
    (Is above cmd is correct way to upgrade ?. )
    I am getting following messages
    ======================================
    Feb 15, 2007 10:54:21 AM oracle.sysman.emcp.EMConfig perform
    INFO: This operation is being logged at /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/emca/kialaprod/emca_2007-02-15_10-53-49-AM.log.
    Feb 15, 2007 10:54:23 AM oracle.sysman.emcp.EMConfig perform
    SEVERE: In-place upgrade of Enterprise Manager for RAC databases is not supported in this release.
    Refer to the log file at /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/emca/kialaprod/emca_2007-02-15_10-53-49-AM.log for more details.
    Could not complete the configuration. Refer to the log file at /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/emca/kialaprod/emca_2007-02-15_10-53-49-AM.log for more details.
    You have new mail in /var/spool/mail/oracle
    ======================================
    Regards,
    Neelesh

  • Activating a DAG database on another server causes Outlook clients to freeze if deleted delegated mailbox in Outlook profile ...

    Hi there,
    We have the following issue in our Exchange 2010/Outlook 2010 environment.
    DAG databases are activated on primary server.
    User "A" adds delegated mailbox "B" to their Outlook mailbox folder list via Account Settings - Change - More Settings - Advanced - Add - OK.  A has Full-Access + Send-As rights set in EMC on B.
    Some time later, mailbox B is deleted.
    User A does not remove B from their folder list. They can see see mailbox B in their folder-list but cannot expand it. Outlook works normally.
    Some time later, the DAG databases are activated on an alternate server.
    Now, whenever user A opens or tries to close  Outlook, it freezes for about 5 minutes. To solve the problem, they need to remove mailbox B via Account Settings - Change - More Settings - Advanced - Remove
    - OK.
    If they don't remove B from their Outlook profile, it continues to freeze on startup/shutdown until the DAG databases are moved back to their primary server.
    Can anyone suggest why this happens and how to avoid it please? I'm thinking of using a logon script to check if mailbox B still exists and remove it from the profile if not. But that will be an ongoing thing to do.
    Environment: Multiple copies of each database in DAG configuration. Two AD sites. Single domain/single forest. We do not have any autodiscover.company.com record in our DNS because we use another solution for remote access.
    Thanks,
    - Alan.

    Hi,
    If you want to get a list of disconnected mailbox, you can use the following command.
    Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -eq "Disabled" } | ft DisplayName,Database,DisconnectDate
    If you want to automatically check for deleted accounts in Outlook every day and remove them, maybe some scripts can help you. You can ask this question in Script forum, you might get better help there. Thanks for understanding.
    http://social.technet.microsoft.com/Forums/scriptcenter/en-US/home?category=scripting
    Best regards,
    Belinda Ma
    TechNet Community Support

  • Inactive sessions in Database

    Hi,
    Lot inactive sessions are in database, Before we bounce database ----> max process got reached, For that we have changed max process and bounced the database but i can see still 75 inactive sessions in database,
    SQL> show parameter process
    NAME TYPE VALUE
    aq_tm_processes integer 1
    db_writer_processes integer 1
    gcs_server_processes integer 0
    job_queue_processes integer 2
    log_archive_max_processes integer 2
    processes integer 200
    SQL> show parameter spfile
    NAME TYPE VALUE
    spfile string
    Then i changed processes to 300
    SQL> show parameter process
    NAME TYPE VALUE
    aq_tm_processes integer 1
    db_writer_processes integer 1
    gcs_server_processes integer 0
    job_queue_processes integer 2
    log_archive_max_processes integer 2
    processes integer 300
    even after bouncing still 75 inactive sessions in database

    Hi,
    What are the events/programs of those sessions?
    Have you started the application or not yet?
    Go through the following documents and see if it helps.
    Note: 427759.1 - How To Prevent Inactive JDBC Connections In Oracle Applications
    https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=427759.1
    Note: 261791.1 - 11i JDBC Thin client connections remain active, MAX PROCESSES REACHED
    https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=261791.1
    Regards,
    Hussein

  • What is a "logged in user" on the "Active Sessions" report in CF8 Server Monitor?

    I was looking at the Active Sessions Report (The Chart View) and saw I have more "logged in users" than "active sessions".
    I had expected them to be nearly the same.    It's on our Intranet where I log users in (using cflogin and cfloginuser) at the begining of their session and users should be logged when the session ends.
    I couldn't find a detailed explaination of what a "logged in user" means.   There is a chance that the same user is logged into a nested application as well as the Intranet, but I don't think that is what I'm seeing.
    I also don't see a way to get a list of what CF is counting as a logged in user.  I can only see a way to get the total count.
    Any help is appreciated. 
    Thanks,
    Jeff

    Thank you Michael for the reply, but I don't think that is the issue.
    When a user opens their browser on the intranet, a session begins and they are logged in (using the cflogin and cfloginuser).    If they close their browser, the session should hang around for 20 min. (per the server setting).   I am assuming this is still considered an "Active Session" since I can see this behavior in the report.
    At first, the Active Sessions and Logged In Users are exactly the same.   When the sessions start to time out, the active sessions are reduced,  but the Logged In Users remain the same.    Then,  after a while, they start to move together.  So I have more Logged In Users than Active Sessions.
    I left the Server Monitor open last night and for most of the night, I had 0 sessions, but 57  "logged in users".   This morning, as people opened their browsers, the Active Sessions and Logged In Users moved together.   The gap of 57 looks consistent.
    It looks like people are remaining logged in after their session ended.
    I am really looking for a detailed explaination of "active session" and/or "logged in user" as used in the server monitor.  It would be really nice to find a way to list the details about each item counted in the "logged in user" and not just the total count. 
    Thanks Again for your reply.
    jsm

  • What is the use of 'ALTER DATABASE CLOSE'?

    Hello Everybody,
    SQL*Plus: Release 10.1.0.2.0 - Production on Ma Aug 15 21:28:30 2005
    Copyright © 1982, 2004, Oracle. All rights reserved.
    Connected to:
    Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
    With the Partitioning, OLAP and Data Mining options
    SQL> conn / as sysdba
    Connected.
    SQL> startup force
    ORACLE instance started.
    Total System Global Area 171966464 bytes
    Fixed Size 787988 bytes
    Variable Size 145750508 bytes
    Database Buffers 25165824 bytes
    Redo Buffers 262144 bytes
    Database mounted.
    Database opened.
    SQL> select status from v$instance;
    STATUS
    OPEN
    SQL> alter database close;
    Database altered.
    SQL> select status from v$instance;
    STATUS
    MOUNTED
    SQL> alter database open;
    alter database open
    ERROR at line 1:
    ORA-16196: database has been previously opened and closed
    If i have to shutdown the instance and database then
    WHAT IS THE USE OF 'ALTER DATABASE CLOSE' ?
    I need explanation. Why should i shutdown?
    Dont give me this answer.
    ORA-16196: database has been previously opened and closed
    Cause: The instance has already opened and closed the database, which is allowed only once in its lifetime.
    Action: Shut down the instance.

    If you read the documentation you will see that there is no ALTER DATABASE CLOSE command.
    This is an undocumented Oracle command, which we are not supposed to use. Consequently we are not allowed to complain about the way that it works. Instead we're supposed to use SHUTDOWN IMMEDIATE.
    Cheers, APC

  • Scalability Issues - Too Many Active Sessions?

    Hello,
    I'm having an issue with an application I built for one of the campuses at the college I work at. The application is a queuing system where there are stations for students to check in, admin stations where staff can see these students and "call" them, and displays outside each employees office that shows the student that was called. There are about 20 of these last type of display panels. I have the following code in my page footer to poll the DB for the most recent called student for a specific room:
    <script type="text/javascript">
    <!--
    var refresh_region = function( workstation_in, div_in ) {
        $.get(
            'wwv_flow.show',
            {"p_request"      : 'APPLICATION_PROCESS=F_NEXT_STUDENT',
             "p_flow_id"      : $v('pFlowId'),      //app id
             "p_flow_step_id" : $v('pFlowStepId'),  //page id
             "p_instance"     : $v('pInstance'),    //session id
             "x01"            : workstation_in
            function(data) {
                $(div_in).html(data);
        setTimeout(function() { refresh_region( workstation_in, div_in ) }, 5000);
    refresh_region( '&P7_WORKSTATION_IN.', '#next_student_div' );
    //-->
    </script>The OnDemand process, F_NEXT_STUDENT runs the following query and returns the result:
    select a.FIRST_NAME || ' ' || a.LAST_NAME
    into   full_name
    from   ONESTOP_QUEUE a
    where  a.WORKSTATION_ID_CALLED = in_workstation_id
    and    a.STATUS = 'CALLED'
    and    a.QUEUE_ID = (
       select min( c.QUEUE_ID )
       from   ONESTOP_QUEUE c
       where  c.WORKSTATION_ID_CALLED = in_workstation_id
    and    c.STATUS = 'CALLED');However, when all of these display panels are turned on (and I use code like this in other pages for similar purposes) the application becomes sluggish and eventually unresponsive. At first we had the application running off a box with Oracle XE. We eventually migrated to a full blown 11g install with APEX Listener and GlassFish. My DBA says everything looks ok on the DB side so I've been trying to dig in other areas to see where the bottleneck may be. After inspecting the Active Sessions report in APEX, I saw that there's a ton of connections being generated (> 30,000). This doesn't seem like a good thing to me and I'm trying to figure out what I'm doing wrong.
    At first I was using $.post() instead of $.()get. I was also using setInterval() instead of a setTimeout() loop. However, none of these changes seemed to really help the situation much. I'm at a loss for how else to improve the performance of this application. Any suggestions on what I can try?
    Most of the app's functionality is on apex.oracle.com
    WORKSPACE: SCCC_TEST
    USER/PASS: TEST/test
    Direct URL to the page (I pass in the worksation ID): http://apex.oracle.com/pls/apex/f?p=65890:7:0::::P7_WORKSTATION_IN:ADMISSIONS_1
    Thanks in advance for any help.

    Hi Patrick,
    UPDATE as of 3PM Eastern:
    This afternoon all users lost the ability to connect to the application. My DBA is still reviewing logs but it seems that the error isn't on the DB side. The application came back up after he restarted the Apex listener. We found a bunch of the following error in the Glassfish server.log file:
    [#|2013-02-25T14:34:39.021-0500|WARNING|oracle-glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=11;_ThreadName=Thread-2;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-80(73).|#]The max threads is currently set to 100.
    After we came back up I went to page 4350:45 and cleared out all sessions. After a couple minutes I rechecked the number of sessions on this page:
    Total Sessions: 27,674
    Distinct Users over all sessions = 2
    Sessions older than 15 minute(s) = 4Seems like way too many sessions to have after just a couple minutes.
    End UPDATE
    Again, thank you for taking the time to reply. Everything seems to be working fine for the past couple days, but I figured I'd provide some current data, especially since I'm still curious about all these "sessions".
    Are we talking about page 4350:45 which shows the following information
    Total Sessions: 9
    Distinct Users over all sessions = 4
    Sessions older than 1 day(s) = 0
    Where does it show 17,400 sessions for you? It almost appears that your daily APEX jobs are not running which do normally purge old APEX sessions automatically. See http://docs.oracle.com/cd/E37097_01/doc/doc.42/e35129/dbms_jobs001.htm
    Yes, this was the page I was referring to. I just checked it now and it showed me the following:
    Total Sessions: 10,236
    Distinct Users over all sessions = 2
    Sessions older than 1 day(s) = 0And it does appear that the APEX jobs are running since there are no sessions older than 1 day... unless I'm interpreting this information incorrectly.
    Also, I was able to get some more data regarding page loading using the Debug info:
    14763     7751818952614     nobody     101     7     show     46     4 seconds ago     0.0000
    14760     7751818952614     nobody     101     7     show     46     9 seconds ago     0.5300
    14757     7751818952614     nobody     101     7     show     46     14 seconds ago     0.0150
    14754     7751818952614     nobody     101     7     show     46     19 seconds ago     0.0160
    14751     7751818952614     nobody     101     7     show     46     24 seconds ago     0.0160
    14748     7751818952614     nobody     101     7     show     46     29 seconds ago     0.0160
    14745     7751818952614     nobody     101     7     show     46     34 seconds ago     0.0160
    14742     7751818952614     nobody     101     7     show     46     39 seconds ago     0.0160
    14739     7751818952614     nobody     101     7     show     46     44 seconds ago     0.0160
    14736     7751818952614     nobody     101     7     show     46     49 seconds ago     0.0160
    14733     7751818952614     nobody     101     7     show     46     54 seconds ago     0.0160
    14730     7751818952614     nobody     101     7     show     46     59 seconds ago     0.0000
    14727     7751818952614     nobody     101     7     show     46     64 seconds ago     0.0160
    14724     7751818952614     nobody     101     7     show     46     69 seconds ago     0.0160
    14721     7751818952614     nobody     101     7     show     46     74 seconds ago     0.0160
    14718     7751818952614     nobody     101     7     show     46     79 seconds ago     0.0160
    14715     7751818952614     nobody     101     7     show     46     84 seconds ago     0.0150
    14712     7751818952614     nobody     101     7     show     46     89 seconds ago     0.5300
    14709     7751818952614     nobody     101     7     show     46     94 seconds ago     0.0000
    14706     7751818952614     nobody     101     7     show     46     99 seconds ago     0.0150
    14703     7751818952614     nobody     101     7     show     46     104 seconds ago     0.0150
    14700     7751818952614     nobody     101     7     show     46     109 seconds ago     0.0150
    14697     7751818952614     nobody     101     7     show     46     114 seconds ago     0.0150
    14694     7751818952614     nobody     101     7     show     46     119 seconds ago     0.0160
    14691     7751818952614     nobody     101     7     show     46     2 minutes ago     0.5310
    14688     7751818952614     nobody     101     7     show     46     2 minutes ago     0.5300
    14685     7751818952614     nobody     101     7     show     46     2 minutes ago     0.5150
    14682     7751818952614     nobody     101     7     show     46     2 minutes ago     0.5300
    14679     7751818952614     nobody     101     7     show     46     2 minutes ago     0.5300
    14676     7751818952614     nobody     101     7     show     46     2 minutes ago     0.5300
    14673     7751818952614     nobody     101     7     show     46     3 minutes ago     0.0000
    14670     7751818952614     nobody     101     7     show     46     3 minutes ago     0.5930
    14667     7751818952614     nobody     101     7     show     46     3 minutes ago     0.5300
    14664     7751818952614     nobody     101     7     show     46     3 minutes ago     0.5460So I'm seeing a page load time of ~0.016 or ~0.53. When I click on the details for one of the longer page view, I get the following:
    0.00000     0.00000     S H O W: application="101" page="7" workspace="" request="APPLICATION_PROCESS=F_NEXT_STUDENT" session="7751818952614"     4
    0.00000     0.04700     Reset NLS settings     4
    0.04700     0.03100     alter session set NLS_LANGUAGE="AMERICAN"     4
    0.07800     0.03100     alter session set NLS_TERRITORY="AMERICA"     4
    0.10900     0.01600     alter session set NLS_CALENDAR="GREGORIAN"     4
    0.12500     0.03100     alter session set NLS_SORT="BINARY"     4
    0.15600     0.00000     alter session set NLS_COMP="BINARY"     4
    0.15600     0.00000     ...NLS: Set Decimal separator="."     4
    0.15600     0.00000     ...NLS: Set NLS Group separator=","     4
    0.15600     0.00000     ...NLS: Set g_nls_date_format="DD-MON-RR"     4
    0.15600     0.00000     ...NLS: Set g_nls_timestamp_format="DD-MON-RR HH.MI.SSXFF AM"     4
    0.15600     0.03100     ...NLS: Set g_nls_timestamp_tz_format="DD-MON-RR HH.MI.SSXFF AM TZR"     4
    0.18700     0.00000     NLS of database and client differs, characterset conversion needed     4
    0.18700     0.01600     ...Setting session time_zone to -05:00     4
    0.20300     0.03100     Reset NLS settings     4
    0.23400     0.03100     alter session set NLS_LANGUAGE="AMERICAN"     4
    0.26500     0.01600     alter session set NLS_TERRITORY="AMERICA"     4
    0.28100     0.03100     alter session set NLS_CALENDAR="GREGORIAN"     4
    0.31200     0.03100     alter session set NLS_SORT="BINARY"     4
    0.34300     0.00000     alter session set NLS_COMP="BINARY"     4
    0.34300     0.00000     ...NLS: Set Decimal separator="."     4
    0.34300     0.00000     ...NLS: Set NLS Group separator=","     4
    0.34300     0.00000     ...NLS: Set g_nls_date_format="DD-MON-RR"     4
    0.34300     0.00000     ...NLS: Set g_nls_timestamp_format="DD-MON-RR HH.MI.SSXFF AM"     4
    0.34300     0.01600     ...NLS: Set g_nls_timestamp_tz_format="DD-MON-RR HH.MI.SSXFF AM TZR"     4
    0.35900     0.03100     ...Setting session time_zone to -05:00     4
    0.39000     0.03100     Setting NLS_DATE_FORMAT to application date format: DD-MON-YYYY HH:MIPM     4
    0.42100     0.01600     Setting NLS_TIMESTAMP_FORMAT to application timestamp format: DD-MON-YYYY HH:MIPM     4
    0.43700     0.03100     Setting NLS_TIMESTAMP_TZ_FORMAT to application timestamp time zone format: DD-MON-YYYY HH:MIPM     4
    0.46800     0.00000     ...NLS: Set g_nls_date_format="DD-MON-YYYY HH:MIPM"     4
    0.46800     0.00000     ...NLS: Set g_nls_timestamp_format="DD-MON-YYYY HH:MIPM"     4
    0.46800     0.00000     ...NLS: Set g_nls_timestamp_tz_format="DD-MON-YYYY HH:MIPM"     4
    0.46800     0.00000     NLS: wwv_flow.g_flow_language_derived_from=0: wwv_flow.g_browser_language=en     4
    0.46800     0.00000     Application 101, Authentication: PLUGIN, Page Template: 61331314513900454147     4
    0.46800     0.00000     Authentication check: No Authentication (NATIVE_DAD)     4
    0.46800     0.00000     ...fetch session state from database     4
    0.46800     0.01600     fetch items (exact)     4
    0.48400     0.00000     ... sentry+verification success     4
    0.48400     0.00000     ...Session ID 7751818952614 can be used     4
    0.48400     0.01500     ...Application session: 7751818952614, user=nobody     4
    0.49900     0.03100     ...Setting session time_zone to -05:00     4
    0.53000     0.00000     Session: Fetch session header information     4
    0.53000     0.00000     Run APPLICATION_PROCESS= request     4
    0.53000     0.00000     ...Execute Statement: begin sys.htp.p( F_NEXT_STUDENT( in_workstation_id => apex_application.g_x01 ) ); end;     4
    0.53000     0.00000     Stop APEX Engine detected     4
    0.53000     -     Final commit     4Again, not sure if I'm reading this correctly but it seems that the steps that are taking the most time seem to be related to NLS settings... and I have translating turned off. This is consistent with all of the longer page views. As a side note, my DBA did turn archive log mode back on this weekend.
    Again, everything seems to be running smoothly at the moment so the above data is more to help satisfy my curiosity about the inner workings of Apex.
    Regards,
    Tadeusz
    Edited by: tdsacilowski on Feb 25, 2013 3:04 PM

  • Hanging Active Sessions in EM from webservice

    I've developed a webservice that uses appmodules for DB persistence. In the OAS 10g (v10.1.3) EM, I'm seeing Active Sessions hanging around for 20 minutes or more after only 2 requests. We're experiencing OAS crashes on OutOfMemoryError events, and seems to be tied to this long hang around time. Heap usage skyrockets with any significant traffic.
    We've scoured the code for hints of open resources such as as open file streams, but can't find any.
    The appmodule is used for one call in each service request. The appmodule is gained from a call to Configuration.createRootApplicationModule(...) and released with a call to Configuration.releaseRootApplicationModule(module, true).
    I've changed the configuration of the appmodule in JDeveloper, reducing jbo.pooltimtolive to 10 mins and jbo.ampool.monitorsleepinterval to 4 mins. I test with the old, default appmodule config in one service instance and the new, reduced-time config in a second service instance on the same server. I send two requests to each instance nearly simultaneously. The active sessions chart in the EM shows identical activity.
    Any hints on how I can get the server to recover memory quickly after the end of a service call? My understanding is that in the servlet model, the server keeps a reference to the servlet, but that after completion on a request of the service method, all other object references should be eligible for garbage collection. We're using the standard Sun JVM, so it seems like we should be seeing more efficient heap recovery and not experiencing OutOfMemoryError. We're only receiving about 100 service calls in a day at present.
    Thanks for any insights.
    Bonus question: Any know how to prevent the heap usage from skyrocketing when the EM is invoked? It's insane!!!

    Hi,
    usually, sessions expire after some time. However, you can manually terminate sessions using the Visual Administrator
    Go to => <System> => <Server> => Services => Security Provider
    Select tab "Login Sessions"
    Switch to "Edit Mode"
    Select session
    Click "Terminate" button
    Best regards,
    Martin

  • Cannot drop undo tablespace with Active extents but no active sessions

    Hi all,
    I am running on 10gr2 oracle database in a Linux 32 bit environment.
    I have a corrupted undo datafile. I've been able to recover the datafile but still the alert logs is still showing that it is corrupted.
    Now what I'm trying to do is to drop the old undo tablespace like the one discussed here Change undo tablespace in Oracle - Switch Oracle's Undo tablespace.
    My problem is I have an Active extent but no active session corresponding to it:
    SYS@ccasdb AS SYSDBA > SELECT a.name,b.status
    FROM   v$rollname a,v$rollstat b
    WHERE  a.usn = b.usn
    AND    a.name IN (
                      SELECT segment_name
                      FROM dba_segments
                      WHERE tablespace_name = 'UNDOTBS1'
                     );  2    3    4    5    6    7    8
    NAME                           STATUS
    _SYSSMU18$                     PENDING OFFLINE
    SYS@ccasdb AS SYSDBA > SELECT a.name,b.status , d.username , d.sid , d.serial#
      2  FROM   v$rollname a,v$rollstat b, v$transaction c , v$session d
      3  WHERE  a.usn = b.usn
      4  AND    a.usn = c.xidusn
      5  AND    c.ses_addr = d.saddr
      6  AND    a.name IN (
      7               SELECT segment_name
      8               FROM dba_segments
      9               WHERE tablespace_name = 'UNDOTBS1'
    10              );
    no rows selected
    but still cannot drop the undotablespace.
    SYS@ccasdb AS SYSDBA > drop tablespace UNDOTBS1 including contents and datafiles;
    drop tablespace UNDOTBS1 including contents and datafiles
    ERROR at line 1:
    ORA-30013: undo tablespace 'UNDOTBS1' is currently in use
    Regards,
    Tim

    Yes i was able to recover the datafile but the alert_log kept on prompting that it is still corrupted. The datafile's status is online.
    I want to kill the session/s contributing to the PENDING OFFLINE status of the rollback segment so I can already drop the undotablespace and so
    that the alert log will stop prompting for that corrupted datafile in that UNDOTABLESPACE.
    Can i Just alter the tablespace's datafiles to offline drop then just drop it. Then I drop the tablespace?

  • SQL 2012 sp1 EE setup disappears when installing Setup Support files ( Error: sqm does not have active session)

    HI Folks,
    WIndows : 2008 R2
    SQL : 2012 sp1 EE
    Setup disappears when installing setup support files On passiive node ( 2  node cluster),  sql is runing on active node without any issue
    Error : SQM does not active session ( In summary detail txt file)
    blog is suggesting . Save the following in a .reg file and merge to populate the registry:  (
    here i am confusing how to save and where to save , how to merge and how to populate) 
    http://blogs.msdn.com/b/sqljourney/archive/2012/05/07/sql-2008-2008-r2-setup-disappears-fails-when-installing-setup-support-files.aspx
    Can you share  your views, if you need any information for clarification. pls let us know for resolution.
    Thanks in Advance.

    Sorry but there is already released  SP2 for SQL Server 2012. Start installation on the passive node first
    Best Regards,Uri Dimant SQL Server MVP,
    http://sqlblog.com/blogs/uri_dimant/
    MS SQL optimization: MS SQL Development and Optimization
    MS SQL Consulting:
    Large scale of database and data cleansing
    Remote DBA Services:
    Improves MS SQL Database Performance
    SQL Server Integration Services:
    Business Intelligence

Maybe you are looking for