Active Session Object

Hi Everyone,
Here is my situation.  I am using a third party application to grab information from SAP.  My issue is that I need to get the most recently used window.  I have tried to use the ActiveSession object, but have had no luck getting application.activesession to work.  Does anyone have experience with this Object?
Any Help would be greatly appreciated.
Thanks
Steve

This would be using VBScript.
Here is the code I am using so far.
Set SapGuiAuto = GetObject("SAPGUI")
Set application = SapGuiAuto.GetScriptingEngine
Set session = application.ActiveSession
field3 = session.findById("usr/ctxtBKPF-BUDAT").text
Thanks
Steve

Similar Messages

  • How to keep track of which tab is currently active in the page using Session object?

    Hi,
    Just curious as to whether it is possible to have a PL/SQL event fire on an active tab.
    The reason is I want to keep track of which tab is currently active on the page is that I have "generic" forms and reports published as portlets that I wish to be able to determine from the session object what page/tab the user is coming from and apply certain restrictions etc.
    kind regards,
    Matt.
    null

    Hi Konstantina,
    Yes You can do like that 2012-->q1-->January
    Steps:
    1. Create time dimension hierarchy as by following like Total--> year--> Quarter--> Month--> if you need you can keep Description.
    2. Drag the Year column from period dimension table to the dimension hierarchy of year.
    3. Drag the quarter column from period dimension table to the dimension hierarchy of Quarter.
    4. Drag the month column from period dimension table to the dimension hierarchy of month.
    5. Drag the hierarchy to period dimension table in presentation layer.
    In Answer side keep as it as Default: drill in primary and secondary interaction under column properties.
    For more refer : http://mkashu.blogspot.com
    Regards
    VG

  • 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

  • No data in Active sessions pie-chart and availability is 0%

    Hi All,
    Does anyone know why my Enterprise Manager cosole in Oracle 10g installed on windows xp professional is not showing any data? Availabilty is always 0% for the instance ORCL and the active sessions pie-chart is always showing 0.01 since May 17,2005.
    Can anyone tell me how to configure EM so that instance ORCL and the active sessions start showing data again?
    Thanks

    Hi,
    Kindly activate the data request. Post that, Under "request available for reporting" a symbol will appear which means that the data has been moved to Active table and is available for reporting at further levels.
    And you can then check for contents in the active table of the DSo, you should get the records.
    Change log: Contains the change history for the delta update from the DataStore object into other data targets, such as DataStore objects or InfoCubes. It makes sense in case of delta uploads.
    Regards,
    hemlata

  • How to get active sessions in tomcat 5.0?

    Hi,
    As I am working on monitoring related requirement, I need to get no. Of active sessions,sessions created, etc.
    I found interesting code in ManagerServlet, As it has some protected methods, I cant call it from its object, I need to create servlet for my work, So I even can't extend ManagerServlet, So I've created one POJO for that, But now I need to populte the context and many other objects,
    Is there any other way out for this?,
    I really appriciate any kind of help. :-)
    -Jeff

    hi :-)
    http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Servlets.html
    or
    http://www.google.com.ph/search?hl=en&q=java+servlet+tutorial&btnG=Google+Search&meta=
    regards,

  • How can I find out if a user has an active session

    How can I find out if a user has an active session or sessionObject in the application Server.
    When a user logs on to my web-application, I want him to be able to see a
    list of all the other users that are also loged on. To do this I need to get a
    list of all the session objects avaliable in the sever at that perticular moment?
    In J2EE 2.1 I found the class "javax.servlet.http.HttpSessionContext" with the method "getIds()"
    that returned all the session Id's. By using the method getSession(java.lang.String sessionId)
    from the same class, you could then retrieve the sessionObject.
    But these methods are depricated (and want to be able to use the
    latest version of J2EE).
    Is there any other way to do this?
    I'm using JBoss application server.

    Check out HttpSessionListener -> http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpSessionListener.html
    Essentially what you have to do is implement this interface. You also have to register the listener in your web.xml, like this:
    <listener>
        <listener-class>
            package.name.YourListener
        </listener-class>
    </listener>sessionCreated() will get called each time the app server creates a session and sessionDestroyed() will get called each time the app server invalidates a session. You could have a Map that contains all the active sessions, and a method for printing a list of all of the active sessions.

  • 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
              > > >
              > > >
              > >
              > >
              >
              >
              

  • How to get active session details

    Dear all
    in my application i want to display number of users online in a list and their details,for that how can i get the active session details in a jsp , or any other ways to do this.any suggestion regarding this is very much helpful to me. thanks in advance
    thanking u
    yours
    kumaran ramu

    Hi,
    You can use a Listener class for track the sessions and do some logic when a session is created/destroyed. See HttpSessionListener interface. You can save the session IDs and session objects when a session is created, for example in a hashmap. Save the hashmap in application context. In your JSP get the hashmap and get its key/values. See thread safe problems if you are using a hashmap in application context.

  • How to obtain a session object from session id

    Hi all,
    let say that I have a list of session ids, and I want by scheduald task to check whether the session is alive\active.
    I saw that the HttpSessionContext was deprecated. (see: http://javasolution.blogspot.com/2007/08/getting-session-object-using-session-id.html)
    Is there any other way to check if the session is alive?

    Do it the other way: let the session itself notify that it is not alive anymore.
    Implement a HttpSessionListener which adds the session to list/set/map on create and removes the session from it on destroy, register it in the web.xml and run it.

  • How to validate a session object in jsp?

    Hi All,
    i am facing a problem.The problem is how to validate the session object object in jsp.I have written a java script by using a defined function as setInterval and has given 5 mintues if the user is idle and will show a pop up menu before time out the session but in case of page active still this pop up menu is coming. The java script as follows.
    function SetTimer(){
         //How long before timeout (should be a few minutes before your server's timeout
         //set timer to call function to confirm update
         if(timeoutMinutes)
         timerObj = setInterval("ConfirmUpdate()",60000);
    function clearTimerFn(){
              timerCount = 0;
              clearInterval(timerObj);
              //timerObj = setInterval("ConfirmUpdate()",60000);
    function ConfirmUpdate(){
         //Ask them to extend
         if(confirm("Your session is about to expire. Press 'OK' to renew your session.")){
              //load server side page if ok
              var url = "ajaxSessionchecker.do?sessionvalidate=sessionvalid";
              LoadXMLDoc(url);
    And in jsp i am calling this js function as
    <%session=request.getSession(false);
              if(session.getLastAccessedTime()==60000){ %>
              <script type="text/JavaScript">
         clearTimerFn();
    </script>
    <%}else{
    session.setMaxInactiveInterval(-1000);} %>
    could you pls help me out?

    The reason for doing this is when ever i come to this user.jsp from account.jsp with a different account number this user.jsp is not refreshed and i still
    see the same old user.jsp for the previous account that i naviated before. Also please let me know if there is any other approach to acheive this taskDoes refreshing the page by pushing F5 solve the problem?
    If so, then the browser is caching the page, despite your attempts to stop it.

  • 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

  • How can i get session object based on session id?

    I have tried searching in forum but i can't find any solution that i can get session object based on session id and i also would like to know how to check whether the session is still active? My company currently using weblogic 5.1. I really hope that some one or anyone can help. I am new in using Servlet. I hope that i can find some answer here. Thank you.

    I have a need to get a Session object from a session id, so I don't think that the above should be deprecated. Here is my use case:
    0. I am displaying files in a file list
    1. I am downloading files.
    2. I am downloading files through a Servlet
    3. I am displaying the files as images in an applet
    4. The applet is ImageJ, and it apparently uses a full URL to download the file.
    5. I use request.getRequestURL() in the applet .jsp to get the full URL (the hostname and port)
    6. My app server is OC4J and it's behind an apache server and is host aliased.
    7. Thus the hostname is different between my applet .jsp and the Servlet URLs
    8. Thus I have 2 different sessions
    9. Thus I need to pass the session id (or some other unique identifier).
    10. I could stored the unique identifier in the application object, but then I would need to clean it up
    11. I cannot pass the the full path to the image due to security problems (what if someone downloads my password file?)
    12. I would like this to work in a clustered environment
    13. I think that WebDAV would solve my problems, since I could pass a full URL of webDAV to ImageJ for download. However, I am unsure how the security of WebDAV would work with ImageJ/URLConnection. I will have to research this feature in ImageJ.

  • Vector and session object...

    Hi, I have a JSP that retrieves a resultset with 3000+ rows. I use that resultset to create a summary page of grouped data, so the resulting page is only a few lines. Each group is a link that can be double clicked to call a JSP that will display the detail line items.
    From a developers viewpoint, this is how I'm doing it: On the first JSP, as I scan through the resultset creating the summary line items I add the detail data to a vector. After I'm done processing the resultset I add the vector to the session object. When the hyperlink on the first JSP is activated I call a second JSP that retreives the vector from the session object and display the results.
    Is that a good idea or a bad idea? It seems to work ok, but I'm thinking it might be alot of data to be storing on a session object especially when you consider the number of users that could be on. Is there a way to compress the vector when I add it to the session object? Is there a better way to do this? Unfortunately, I can't re-retrieve the data because the SQL takes too long. Thanks!

    Sure you could compress it... you could use the classes in java.util.zip, and use an ObjectOutputStream plus a ZipOutputStream plus a ByteArrayOutputStream (I think), using zip compression to convert your Vector into an array of bytes, and then do the reverse when you needed the data uncompressed. Chances are that would compress your data by about 80 or 90%.
    Here you would be making the classic tradeoff between memory usage and processing time; I wouldn't do this compression thing until it was clear that it was necessary, though.

  • Kill an Active Session

    Is there any way to interrogate active session information? I'd like to determine what sql and/or ADF object information is being used by the session and to kill that session in the oc4j container.

    That could be done by views in the database. v$session for a start.
    Regards.

  • Active Session - Identification

    Hi everyone!
    We are implementing an application security wherein a user logged-in to the system can not re-login into another workstation (other session) unless the user has closed or terminated the first session.
    I would like to ask if there's a way to identify active sessions in the server. This would help us in implementing our design needed for this application security.
    We are using Tomcat as our web application server.
    Thanks in advance!

    You can do one thing,
    1. Create a bean which will store userName and session id.
    2. On successful login, you push the values into this bean and add the bean to the servletcontext or JSP's application object.
    For example, if user XXXX was logged in, your bean,
    UserBean b = new UserBean();
    b.setName("XXXX");
    b.setSessionId(session.getId());
    application.setAttribute("XXXX",b);
    3. For further login, you check whether user XXXX is existing in the application, if existing, get the session id and check for the session (whether alive), if yes, reject the login otherwise modify the bean, add new session id and allow the user into your application.
    Hope this helps.
    Sudha

Maybe you are looking for