Discussions
Categories
- 197.1K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.7K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 555 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.4K SQL Developer
- 296.3K Development
- 17 Developer Projects
- 139 Programming Languages
- 293K Development Tools
- 110 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 158 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 205 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 468 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 Portuguese
Last_call_et keeps resetting, no other evidence of activity

I'm trying to debug an issue with a process that pulls a bunch of data into an Access database from a couple of Oracle databases (yes, we're working on killing Access). Almost everything I can see is telling me that Oracle is doing nothing and it's purely an Access issue but last_call_et in v$session keeps resetting itself which makes me believe that Oracle is doing something. I'd be really appreciative if anyone can help me figure out what I'm missing.
What I'm Seeing
When I query gv$session, I'm seeing the session that Access opened. Every time I look, the status is INACTIVE, sql_id is NULL, and prev_sql_id is a constant value. When I look at gv$sql for that prev_sql_id, executions isn't increasing and executions = end_of_fetch_count. So far, so good, Oracle's off the hook.
However, when I pull in LAST_CALL_ET from gv$session, that value never gets above 10 seconds. It's constantly resetting. That makes me believe that Oracle is doing something every few seconds. But I can't for the life of me think of anything that it could possibly be doing that wouldn't cause a change in prev_sql_id or a change in the number of executions of the SQL statement.
Is there something that I'm overlooking here?
Thanks!
Justin
Best Answer
-
JustinCave wrote: gv$session_wait_history is reporting events of SQL*Net message to client SQL*Net message from client It does appear that the Access changes resolved the overall issue. But while Access was chugging away, I was still seeing LAST_CALL_ET getting reset with no other obvious signs of activity. Justin
If it was changing between FROM and TO there must have been some message coming from Access and bouncing back without an error. Possibly some sort of OCI "ping" type call that didn't involve an SQL statement.
Update: something like a "set context" or "set client identifier" perhaps; possibly a (non-SQL) rollback or commit
Regards
Jonathan Lewis
Answers
-
Which version of Oracle ?
What does v$session_wait_history show for that session.
What do you see as the state and event over a short set of queries to v$session for that sid ?
Regards
Jonathan Lewis
-
Sorry.
The database is 11.2.0.3 on AIX.
I'll take a look at gv$session_wait_history momentarily, we've killed the process and are restarting after giving the Access database a couple good kicks in the pants.
Justin
-
gv$session_wait_history is reporting events of
SQL*Net message to client
SQL*Net message from client
It does appear that the Access changes resolved the overall issue. But while Access was chugging away, I was still seeing LAST_CALL_ET getting reset with no other obvious signs of activity.
Justin
-
JustinCave wrote: gv$session_wait_history is reporting events of SQL*Net message to client SQL*Net message from client It does appear that the Access changes resolved the overall issue. But while Access was chugging away, I was still seeing LAST_CALL_ET getting reset with no other obvious signs of activity. Justin
If it was changing between FROM and TO there must have been some message coming from Access and bouncing back without an error. Possibly some sort of OCI "ping" type call that didn't involve an SQL statement.
Update: something like a "set context" or "set client identifier" perhaps; possibly a (non-SQL) rollback or commit
Regards
Jonathan Lewis