Number of Active Sessions?

Is there a query that can tell us if users are actively using an APEX application? For example, before we restart the server, we would like to be able to run a query (or whatever it might be) to find out who has an active APEX session (within the past 10 or 15 minutes) so we'll know to contact the user(s) beforehand. If we have to we usually restart the server first thing in the morning, but we've found that there are some early birds in the office that we weren't expecting.
Thank you,
Tammy

Hello,
How about something like -
select
  distinct apex_user
from
  apex_workspace_activity_log
where
  application_id = 123
and
  view_date > (sysdate - 1/24)Obviously adjust the application_id and the time interval to suit your own requirements (in that example it looks for sessions within the last hour).
You will need to run this query from within the same workspace as your application.
Hope this helps,
John.
Blog: http://jes.blogs.shellprompt.net
Work: http://www.apex-evangelists.com
Author of Pro Application Express: http://tinyurl.com/3gu7cd
REWARDS: Please remember to mark helpful or correct posts on the forum, not just for my answers but for everyone!

Similar Messages

  • The number of active sessions isn't decreasing in OC4J instance

    Hi Guru’s,
    Could you help me, please?
    The number of active sessions isn’t decreasing in OC4J instance after our clients closed the application.
    Our partner use Oracle AS 10gR3 (10.1.3.4.0) with J2EE and HTTP mode.
    When we monitoring our OC4J instance with Performance tab on Oracle EM, we appreciate that the value of Active Sessions on ‘Servlets and JSPs’ are very high. If users close our applications, then number of active sessions isn’t decreasing and active status isn’t becoming inactive.
    Which OC4J settings responsible for managing active sessions and how can I get more information about the active session details?
    Thanks in advance,
    Zoltan

    Dinesh.Rajak wrote:
    When I deployed this code Tomcat, it is giving the output as 0, hence tried with accessing the jsp file in multiple browsers but still it is showing the count of active session as 0 - plz helpPlease, don't resurrect old threads, and it's still the wrong forum. Create a new thread if you have a specific question, and create the thread in the correct forum. I'm closing this thread.
    Kaj

  • [Forum FAQ] Restrict number of Active Sessions in RDS 2012 and 2012 R2

    As everyone knows with the introduction of Windows Server 2012 & 2012 R2, there are various changes and no more availability for RDSH configurations or Remote Desktop Service Manager;
    now we can manage all the settings under Server Manager and group policy.
    Configuration 1: Remote Desktop Timeout settings:
    Here, we will see the Remote Desktop timeout settings. You can maintain the settings under below mention path (Figure 1 and Figure 2).
    Open the
    Server Manager, select Remote Desktop Services.
    In Remote desktop Services, in right side you can drop down to
    collections.
    Select the
    collection which you want to edit the settings.
    Under
    collections Properties, select Task and then Edit Properties.
    In Properties dialog box, select
    Session.
    You can find all the
    timeout settings under session collection properties; edit according to your requirements and then
    OK.
    Figure 1: Selecting Collection Properties
    Figure 2: Configuring screen for Timeout and reconnection Settings
    Group policy setting:
    The same settings can also be applied by Group Policy.
    You can also configure timeout and reconnection settings by applying the following Group Policy settings, you can check the figure 3 for graphical view.
    Set time limit for disconnected sessions
    Set time limit for active but idle Remote Desktop Services sessions
    Set time limit for active Remote Desktop Services sessions
    End session when time limits are reached
    In addition to this another group policy available with the help of which you can bale to set time limit for logging off the RemoteApp according to our desired time. This setting
    can be applied with addition to above mentioned policy.
    Set time limit for logoff of RemoteApp Sessions
    These Group Policy settings are located in the following locations:
    Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits
    User Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits
    These Group Policy settings can be configured by using either the Local Group Policy Editor or the Group Policy Management Console (GPMC).
    Note:
    These Group Policy settings will take precedence over the settings configured in Remote Desktop Session Host Configuration. If both the Computer Configuration and the User Configuration policy
    settings are configured, the Computer Configuration policy settings take precedence.
    Figure 3: Group Policy for setting Timeout and reconnection setting
    Configuration 2:
    Restrict & Enable user to a single & multiple session
    Under Windows Server 2012 & 2012 R2, there is no specific setting under RDP-TCP as it is not available.
    Restrict User to Single session:
    To restrict the user to single session (Disable Multiple RDP Session) you can configure the setting under group policy (Figure 4).
    Computer Configuration\ Administrative Templates\ Windows Components\ Remote Desktop Services\ Remote Desktop Session Host\ Connections
    Restrict Remote Desktop Services users to a single Remote Desktop Services session     Enabled
    Figure 4: Group policy for Restrict user to Single session
    Enable user to multiple session:
    To enable the user to multiple session you can configure the setting under below (Figure 5).
    Computer Configuration\ Administrative Templates\ Windows Components\ Remote Desktop Services\ Remote Desktop Session Host\ Connections
    Restrict Remote Desktop Services users to a single Remote Desktop Services session     Disabled
    Figure 5: Group Policy for Enable user to Multiple Session
    In addition you can also edit the registry setting for allowing multiple RDP session as per below (Figure 6).
    HKEY_Local_Machine\SYSTEM\CurrentControlSet\Control\Terminal Server
    fSingleSessionPerUser     REG_DWORD     0x00000000
    Note: By default the registry value is set to 1, but you need to change to 0.
    Figure 6: Display the registry settings
    Also you can edit the policy “Limit number of connections” and set RD Maximum collection as per your company
    requirements (Maximum limit: 999999) for above mention group policy path (Figure 7).
    Figure 7: Group Policy for Limit number of Connections
    Apart from this, if you have not specified any policy or registry setting and still you want to restrict the new session, then in Windows Server 2012 & 2012 R2 there is option where you
    need to follow below steps (Figure 8 and Figure 9).
    Right click a Remote Desktop Session Host in specified location of Host Server and select “Do not allow new connections”.
    After clicking that it will ask you for your confirmation, click yes and no new connection will be allowed.
    Figure 8: Setting displaying “Do not allow new connections”
    Figure 9: Confirmation popup
    RD Gateway Connection Properties:
    If you have deployed RD Gateway under your environment you can also limit the number of simultaneous connections through RD Gateway by configuring
    policy under RD Gateway Manager. For this you need to follow below mention path.
    Open RD Gateway Manager, select the server which you want to modify.
    Right click Properties.
    Under General Tab
    -Limit maximum allowed simultaneous
    connections to:Specify the number of connection you want to able to provide connection.
    -Allow the maximum
    supported simultaneous connections:This
    setting will allow maximum supported connections at a time.
    -Disable new connections:This
    setting will not allow new connections through RD Gateway but Active connection will not be automatically disconnected.
    Select the option as per requirement which able to allow the connection
    Figure 10: Connections setting under RD Gateway Manager
    Configuration 3: Configure keep-alive connection interval
    As per above mention in initial post you can able to change the setting for Keep alive connection interval. In addition to this also verify the
    registry setting must be set as per following (Figure 11 and Figure 12).
    HKEY_Local_Machine \ SOFTWARE \ Policies \ Microsoft \ Windows NT \ Terminal Services
    KeepAliveEnable       REG_DWORD           0x00000001 (1)
    KeepAliveInterval     
    REG_DWORD           0x00000001 (1)
    Figure 11: Group Policy setting for Keep alive
    Figure 12: Registry setting for keep alive
    If you need further assistance, welcome to post your questions in our
    Remote Desktop Services (Terminal Services) forum.
    If you would like to achieve this in Windows Server 2008 or Windows Server 2008 R2, please move on to the next post.

    Applies to Windows Server 2008 and Windows Server 2008 R2
    Configuration 1: Remote Desktop Timeout settings:
    1. Open the property dialog for RDP-Tcp connection in Remote Desktop Services Manager.
    2. In the Sessions tab, you can configure the following settings:
    Active Session Limit
    Idle session limit
    Action when session limit is reached or connection is broken
    End a disconnected session
    Additionally, you can configure the settings with the help of Group Policy also by below mention path.
    Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits
    User Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits
    Configuration 2: Restrict each user to a single session
    By using this configuration or policy setting, each user can only maintain one session to the certain terminal server; when another session is started by the same user, the original one will
    lose the connection. In that way, the total number of possible active sessions won’t exceed the total remote users. You can implement this as below mention steps.
    Remote Desktop Host (RDP-Tcp) configuration:
    Edit Settings – Restrict each user to a single session: Yes
    Group Policy: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop
    Services (Terminal Services)\Remote Desktop Services Session Host (Terminal Server)\Connections\
    Restrict Remote Desktop Services (Terminal Services) users to a single remote session:    Enabled
    Configuration 3: Configure keep-alive connection interval
    By specifying the minutes that the TS holds a remote session actually disconnected, the server will detect the session status after each period. The session that are actually offline will
    be changed to disconnected status:
    Group Policy:  
    Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services (Terminal Services)\Remote Desktop Services Session Host (Terminal Server)\Connections\
    Configure keep-alive connection interval:         Enabled and Specify the Value
    Please click to vote if the post helps you. This can be beneficial to other community members reading the thread.

  • Any way to get number of active sessions

    Hi,
              With the deprecation of the HttpSessionContext interface as of Servlet API
              2.1 for security reasons, is there any way to know how many sessions are
              currently active in a given WebLogic instance?
              Thanks,
              Sanjiv
              

    You could make it a singleton. The overhead is nothing ... trust me. Run
              WebLogic through a profiler if you don't ;-)
              Good luck,
              Cameron Purdy, LiveWater
              "Sanjiv Gulati" <[email protected]> wrote in message
              news:[email protected]...
              > Thanks for sharing this technique. Although I haven't used the
              > HttpSessionBindingListener interface myself, this will work as long as I
              add
              > an instance of SessionCounter in each new session. The only modifications
              > I'll add to the code below would be a synchronized block within the
              > valueBound and valueUnbound methods so that modifications to m_cSessions
              are
              > thread safe.
              >
              > The overhead associated with this approach will be the following:
              > 1) For every session there will be an associated SessionCounter, and
              > 2) Serialization of requests that end up invoking the valueBound &
              > valueUnbound methods.
              >
              > But I guess this cannot be avoided.
              >
              > Thanks,
              > Sanjiv
              >
              > Cameron Purdy <[email protected]> wrote in message
              > news:[email protected]...
              > > The only portable implementation is to have all requests go through your
              > > servlet code (or JSP code) and check if the session is new
              > > (HttpSession.isNew). If so, register a value with the session that
              > > implements HttpSessionBindingListener. Something like:
              > >
              > > class SessionCounter implements HttpSessionBindingListener {
              > > // count of active sessions
              > > private static int m_cSessions;
              > > // accessor for count of active sessions
              > > public int getSessionCount() {
              > > return m_cSessions;
              > > }
              > > // this object placed on a session
              > > void valueBound(...) {
              > > ++m_cSessions;
              > > }
              > > // this object removed from a session
              > > void valueUnound(...) {
              > > --m_cSessions;
              > > }
              > > // end class
              > > }
              > >
              > > It is host-local ... meaning it only tracks one host in a cluster.
              > > Actually, it only tracks sessions within one classloader on one host in
              a
              > > cluster, but don't worry about that distinction.
              > >
              > > And no, I've never done it, but it is apparent that you could, if you
              > chose
              > > to:
              > >
              > > 1) Count sessions
              > > 2) Track all session instances
              > > 3) Have session-level events, such as onCreate/onDestroy
              > >
              > > Hope it helps,
              > >
              > > Cameron Purdy, LiveWater
              > >
              > > "Sanjiv Gulati" <[email protected]> wrote in message
              > > news:[email protected]...
              > > > Hi,
              > > >
              > > > With the deprecation of the HttpSessionContext interface as of Servlet
              > API
              > > > 2.1 for security reasons, is there any way to know how many sessions
              are
              > > > currently active in a given WebLogic instance?
              > > >
              > > > Thanks,
              > > > Sanjiv
              > > >
              > > >
              > >
              > >
              >
              >
              

  • Limit Number of active sessions for wlan user in Cisco Prime

    Is there a way to limit the number of logins from a particular set of credentials in Cisco Prime 2.1? I want to set a maximum of 2 logins from a particular user on the wlan. I have a guest wlan using layer 3 security and an internal wlan using RADIUS (Windows). Would appreciate the help

    There is, but it isn't due to PI. It is a function of the WLC itself.
    Under Security, there is a Concurrent User Login, set to 0(which is default) it is unlimited logins. This value can be changed to be the number of concurrent logins that work for your situation.
    Be advised, this is not a Per WLAN setting, it is a controller wide setting.
    HTH,
    Steve

  • 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

  • How to access "Active Sessions" using MBeans

    Hi all,
    I have deployed an application at EM (Enterprise Manager).
    when I logged into EM and click the application I can see the number of active sessions under "Servlets and JSPs" topic.
    how can I access that parameter at application level..??
    (I want to access that parameter *"x"* at my web application and display Logged in users : x )
    EM shows that the number of active sessions. it updates too.. so there must be some bean or record for that parameter..
    how can I access that....??
    Regards,
    Dinuka.

    You can use something like the following:
    package middleware.magic;
    import javax.management.MBeanServerConnection;
    import javax.management.ObjectName;
    import javax.management.remote.JMXConnector;
    import javax.management.remote.JMXConnectorFactory;
    import javax.management.remote.JMXServiceURL;
    import javax.naming.Context;
    import java.io.IOException;
    import java.util.Hashtable;
    public class Browse {
        private String hostname = "172.31.0.106";
        private Integer port = 7001;
        private String username = "weblogic";
        private String password = "transfer11g";
        private String protocol = "t3";
        private String jndiRoot = "/jndi/";
        private String mBeanServer = "weblogic.management.mbeanservers.domainruntime";
        private String serviceName = "com.bea:Name=DomainRuntimeService,Type=weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean";
        private JMXConnector connector;
        public static void main(String[] args) {
            Browse test = new Browse();
            try {
                MBeanServerConnection connection = test.getMBeanServerConnection();
                test.getSomeInformation(connection);
                test.closeJmxConnector();
            } catch (Exception e) {
                e.printStackTrace();
        public void getSomeInformation(MBeanServerConnection connection) throws Exception {
            ObjectName service = new ObjectName(serviceName);
            ObjectName[] serverRunTimes = (ObjectName[]) connection.getAttribute(service, "ServerRuntimes");
            for (int i = 0; i < serverRunTimes.length; i++) {
                String name = (String) connection.getAttribute(serverRunTimes, "Name");
    String version = (String) connection.getAttribute(serverRunTimes[i], "WeblogicVersion");
    String state = (String) connection.getAttribute(serverRunTimes[i], "State");
    System.out.println("Server name: " + name + ", Version: " + version + ", Server state: " + state);
    for (int i = 0; i < serverRunTimes.length; i++) {
    ObjectName[] applicationRuntimes = (ObjectName[]) connection.getAttribute(serverRunTimes[i], "ApplicationRuntimes");
    for (int j = 0; j < applicationRuntimes.length; j++) {
    String name = (String) connection.getAttribute(applicationRuntimes[j], "Name");
    ObjectName[] componentRuntimes = (ObjectName[]) connection.getAttribute(applicationRuntimes[j], "ComponentRuntimes");
    System.out.println("Application name: " + name);
    for (int k = 0; k < componentRuntimes.length; k++) {
    if (connection.getAttribute(componentRuntimes[k], "Type").equals("WebAppComponentRuntime")) {
    String componentName = (String) connection.getAttribute(componentRuntimes[k], "Name");
    Integer sessionsCurrent = (Integer) connection.getAttribute(componentRuntimes[k], "OpenSessionsCurrentCount");
    Integer sessionsHigh = (Integer) connection.getAttribute(componentRuntimes[k], "OpenSessionsHighCount");
    System.out.println(" - Component Name: " + componentName + ", Sessions Current: " + sessionsCurrent + ", Sessions High: " + sessionsHigh);
    public MBeanServerConnection getMBeanServerConnection() throws IOException {
    return getJmxConnector().getMBeanServerConnection();
    public JMXConnector getJmxConnector() throws IOException {
    JMXServiceURL serviceURL = new JMXServiceURL(protocol, hostname, port, jndiRoot + mBeanServer);
    Hashtable hashtable = new Hashtable();
    hashtable.put(Context.SECURITY_PRINCIPAL, username);
    hashtable.put(Context.SECURITY_CREDENTIALS, password);
    hashtable.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");
    connector = JMXConnectorFactory.connect(serviceURL, hashtable);
    return connector;
    public void closeJmxConnector() throws IOException {
    connector.close();
    Information regarding runtimeMBean can be found here: http://download.oracle.com/docs/cd/E12839_01/apirefs.1111/e13951/core/index.html.
    Open the tree Runtime MBeans, ServerRuntimeMBean and click attributes to see the available attributes (such as Name, WeblogicVersion, State etcetera).
    An example output of the program above:Server name: AdminServer, Version: WebLogic Server 10.3.2.0 Tue Oct 20 12:16:15 PDT 2009 1267925 , Server state: RUNNING
    Server name: soa_server1, Version: WebLogic Server 10.3.2.0 Tue Oct 20 12:16:15 PDT 2009 1267925 , Server state: RUNNING
    Application name: FMW Welcome Page Application_11.1.0.0.0
    - Component Name: AdminServer__11.1.0.0.0, Sessions Current: 0, Sessions High: 0
    Application name: Module-FMWDFW
    Application name: bea_wls_internal
    - Component Name: AdminServer_/bea_wls_internal, Sessions Current: 0, Sessions High: 0
    Application name: mds-soa
    Application name: bea_wls_deployment_internal
    - Component Name: AdminServer_/bea_wls_deployment_internal, Sessions Current: 0, Sessions High: 0
    Application name: wsil-wls
    - Component Name: AdminServer_/inspection.wsil, Sessions Current: 0, Sessions High: 0
    Application name: bea_wls_diagnostics
    - Component Name: AdminServer_/bea_wls_diagnostics, Sessions Current: 0, Sessions High: 0
    Application name: mejb
    Application name: bea_wls9_async_response
    - Component Name: AdminServer_/_async, Sessions Current: 0, Sessions High: 0
    Application name: uddiexplorer
    - Component Name: AdminServer_/uddiexplorer, Sessions Current: 0, Sessions High: 0
    Application name: mds-owsm
    Application name: bea_wls_management_internal2
    - Component Name: AdminServer_/bea_wls_management_internal2, Sessions Current: 0, Sessions High: 0
    Application name: consoleapp
    - Component Name: AdminServer_/console, Sessions Current: 0, Sessions High: 2
    - Component Name: AdminServer_/consolehelp, Sessions Current: 0, Sessions High: 1
    Application name: DMS Application_11.1.1.1.0
    - Component Name: AdminServer_/dms_11.1.1.1.0, Sessions Current: 0, Sessions High: 0
    Application name: em
    - Component Name: AdminServer_/em, Sessions Current: 0, Sessions High: 0
    Application name: uddi
    - Component Name: AdminServer_/uddi, Sessions Current: 0, Sessions High: 0
    Application name: MQSeriesAdapter
    Application name: OraSDPMDataSource
    Application name: JmsAdapter
    Application name: uddi
    - Component Name: soa_server1_/uddi, Sessions Current: 0, Sessions High: 0
    Application name: wsil-wls
    - Component Name: soa_server1_/inspection.wsil, Sessions Current: 0, Sessions High: 0
    Application name: SOAJMSModule
    Application name: DbAdapter
    Application name: bea_wls9_async_response
    - Component Name: soa_server1_/_async, Sessions Current: 0, Sessions High: 0
    Application name: composer
    - Component Name: soa_server1_/soa/composer, Sessions Current: 0, Sessions High: 0
    Application name: DMS Application_11.1.1.1.0
    - Component Name: soa_server1_/dms_11.1.1.1.0, Sessions Current: 0, Sessions High: 0
    Application name: Module-FMWDFW
    Application name: usermessagingdriver-email
    - Component Name: soa_server1_/sdpmessagingdriver/email-mbeanlifecycle, Sessions Current: 0, Sessions High: 0
    Application name: UMSJMSSystemResource
    Application name: AqAdapter
    Application name: FtpAdapter
    Application name: OracleBamAdapter
    Application name: SOADataSource
    Application name: usermessagingserver
    - Component Name: soa_server1_/sdpmessaging/mbeanlifecycle, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/sdpmessaging/parlayx, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/sdpmessaging/userprefs-ui, Sessions Current: 0, Sessions High: 0
    Application name: bea_wls_internal
    - Component Name: soa_server1_/bea_wls_internal, Sessions Current: 0, Sessions High: 0
    Application name: SocketAdapter
    Application name: SOALocalTxDataSource
    Application name: FileAdapter
    Application name: DefaultToDoTaskFlow
    - Component Name: soa_server1_/DefaultToDoTaskFlow, Sessions Current: 0, Sessions High: 0
    Application name: soa-infra
    - Component Name: soa_server1_/soa-infra, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/TaskService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/TaskMetadataService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/TaskQueryService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/TaskReportService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/IdentityService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/UserMetadataService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/RuntimeConfigService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/TaskEvidenceService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/CompositeMetadataService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/b2b, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/b2b, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/AGMetadataService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/AGQueryService, Sessions Current: 0, Sessions High: 0
    - Component Name: soa_server1_/integration/services/AGAdminService, Sessions Current: 0, Sessions High: 0
    Application name: wsm-pm
    - Component Name: soa_server1_/wsm-pm, Sessions Current: 0, Sessions High: 0
    Application name: mds-owsm
    Application name: b2bui
    - Component Name: soa_server1_/b2bconsole, Sessions Current: 0, Sessions High: 0
    Application name: bea_wls_diagnostics
    - Component Name: soa_server1_/bea_wls_diagnostics, Sessions Current: 0, Sessions High: 0
    Application name: bea_wls_cluster_internal
    - Component Name: soa_server1_/bea_wls_cluster_internal, Sessions Current: 0, Sessions High: 0
    Application name: EDNLocalTxDataSource
    Application name: EDNDataSource
    Application name: uddiexplorer
    - Component Name: soa_server1_/uddiexplorer, Sessions Current: 0, Sessions High: 0
    Application name: bea_wls_deployment_internal
    - Component Name: soa_server1_/bea_wls_deployment_internal, Sessions Current: 0, Sessions High: 0
    Application name: worklistapp
    - Component Name: soa_server1_/integration/worklistapp, Sessions Current: 0, Sessions High: 0
    Application name: mds-soa
    Application name: OracleAppsAdapter

  • Scale up curve on "Average Active Sessions"

    In Grid Control 11g, Targets -> Databases -> Performance, the Average Active Sessions graph has the curve very low, almost near the bottom X axis. I know we don't have many active sessions. But it's also because this is a 4-node RAC with 96 CPUs in total. Without artificially reducing the CPU count, is there a way to scale up the curve so it does not "crawl" at the bottom? (It would be ideal if it could be manually controlled at will so when the number of active sessions does go through the roof, I can bring down the scale.)

    Hi,
    Did you get answer to your query ? I'm also looking for answer for this.
    Basically, my requirement is get user impact due to any outage and I would like to know trend of users in the system at any given point of time.

  • Monitor Activity - Active Sessions : Not displaying all sessions

    I'm encountering an issue whereby the active sessions are not being listed in the Monitor Activity -> Active Sessions screen.
    However, the number of Active Sessions is being displayed.
    Any ideas?

    Hi Dave,
    I think there's some confusion here. The select list right after the label Display is for you to select the maximum number of rows you want to display on the report. The actual number of sessions in the report will be shown below.
    I did this just now on apex.oracle.com. I chose a value of 15 (the default) for Display. And at the split second that I clicked Go, there were only 4 active database sessions - and the pagination label at the bottom of the report was "1 - 4", which was correct.
    I just think you're misinterpreting Display.
    Joel

  • Find Number of Active Calendar Client Sessions?

    What is the "ps" command to find the number of active Calendar clients at any given time?
    We are using 10.1.2 in an OCS installation on Linux SuSe servers.
    Also, is there a way to see the individual usernames associated with each active session?

    On e.g. UNIX you can perform
    netstat -a | grep 7778 (mid web calendar port on my system)
    (http://<your host>:7778/ocas-bin/ocas.fcgi?sub=web&web=calendar&view=day)
    Best regards,
    Fred

  • Determine number of active jsp /self service sessions in EBS 11i/R12

    Hi,
    Can someone let me know , how can I find the number of active jsp/self service sessions in EBS 11i/R12.
    Thanks
    Dev

    Hi;
    Please check below threads which could be helpful for your issue:
    11i : Oracle Application Object Library Active Users Data Collection Test [ID 233871.1]
    Session monitoring tool
    Session monitoring tool
    Regard
    Helios

  • How to find active sessions count on a server in weblogic server console

    Hi All,
    I would like to know how to find active sessions count on a server in weblogic console. I am using weblogic 11g.
    Regards,
    Sunil.

    On the deployment, monitoring tab, you can select web applications. Here the number of current sessions are listed per web application deployed on the domain.
    The deployment itself (deployments, application, monitoring, sessions) shows a list of sessions and where it is located. Unfortunately, there is no aggregation (but that is something you can so yourself as well).
    When you are using a load balancer in front, the count of sessions on per web application on the domain gives you some clue how many sessions there are present on each server.
    That is to say, when load balancer is using round-robin (and does that correct), you can take the total number of sessions divide it by the number of servers.

  • Check the number of active users of oc4j in EBS

    Hi,
    I often see a recommndation of sizing jvm's to 1 per 100 active users. How can I find the number of active users currently using a jvm in EBS. We have 4 apps servers and 1 of apps servers also runs OBIEE with it's own jvm.
    I can find out from a unix command prompt counting establish connections to the port but I like to know if there's a better way to find the number of active users using the jvm's
    Thanks
    Mike

    Hi,
    To find the number of active user session on each of the application servers from a unix command line. I would find the port that Apache was listening on eg 8100. The use the following command on each of the apps servers
    netstat -an | grep 8100 | grep -i est | wc -l
    This gives a rough idea of how many active connections are established to the apps server. But I would really like to find how many users are actively using o4cj.
    If you are using forms in socket mode again, you can grep on the forms listening port number to find how many active forms users are connected.
    I can also see how many active connections are in the oc4j established to the database using lsof. Find the process id for oacore jvm.
    lsof -p PID
    But I'm sure there's a better and more accurate way of find active users of o4cj, specifically oacore.
    Thanks
    Mike

  • How to know the number of Active users logged in to a Essbase  Application?

    Hi,
    Is there way to capture/log the number of active users who have logged into a particular Essbase application at a given time.
    In Essbase or in Shared services?
    I know we can see the EAS-Edit Sessions shows the actively logged-in users, then we can sort on the application/database & manually count the number.
    Is there a way to capture it in a log at a given time on a regular basis. Any MAXL or Shared services feature?
    Appreciate your thoughts.
    Thanks,
    Ethan.

    You could use maxl .
    display user all;
    there will be a column called "logged in" which will display true/false for the users
    but that will just show if they are logged into the server and not the application
    You can also use use display session
    display session all;
    or
    display session on application sample;
    which should show what you are after.
    Cheers
    John
    http://john-goodwin.blogspot.com/

  • 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

Maybe you are looking for