From: Mikhail Velikikh <>
Date: Sun, 27 Dec 2020 00:17:30 +0000
Message-ID: <>

Hi Dimitre,

Once I have seen it in an environment with ORDS/APEX. Another time it was due to failed JDBC connections. Since ORDS uses JDBC, I think it is mostly JDBC related rather than OAuth authentication itself.

I can reproduce it with the following Java class that uses invalid database credentials so as to receive ORA-1017:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class JDBCExample {

    public static void main(String[] args) {


        // auto java.sql.Driver discovery -- no longer need to load a java.sql.Driver class via Class.forName

        // register JDBC driver, optional since java 1.6
        /*try {

} catch (ClassNotFoundException e) {
e.printStackTrace(); }*/ // Oracle SID = orcl , find yours in tnsname.ora try (Connection conn = DriverManager.getConnection( "jdbc:oracle:thin:_at_//localhost/XEPDB1", "x", "y")) { if (conn != null) { System.out.println("Connected to the database!"); } else { System.out.println("Failed to make connection!"); }
} catch (SQLException e) {
System.err.format("SQL State: %s\n%s", e.getSQLState(), e.getMessage());
} catch (Exception e) {
e.printStackTrace(); }


I enabled SQL*Net server trace, and I also fired a script polling v$session.
That is what I got in v$session - user#=0, top_level_call#=115 which corresponds to OAUTH in my XE database.



* <USER_x0023_>0</USER_x0023_>*
    <MODULE>JDBC Thin Client</MODULE>
* <TOP_LEVEL_CALL_x0023_>115</TOP_LEVEL_CALL_x0023_>*
    <LOGON_TIME>26.12.2020 23:52:24</LOGON_TIME>

* <EVENT>Failed Logon Delay</EVENT>*

select * from v$toplevelcall where top_level_call#=115;


  • ---------- *115 *OAUTH 0

This is the relevant part of my SQL*Net trace file processed by trcasst:

---> Send 241 bytes - Data packet timestamp=020-12-26 23:52:24.270 Set protocol (TTIPRO)

        Operation 01 (con) Send protocol version=6
        Originating platform: x86_64/Linux 2.4.xx

<--- Received 2684 bytes - Data packet timestamp=020-12-26 23:52:24.843 Set datatypes (TTIDTY)

---> Send 2697 bytes - Data packet timestamp=020-12-26 23:52:24.851 Set datatypes (TTIDTY)

<--- Received 169 bytes - Data packet timestamp=020-12-26 23:52:24.937 Start of user function (TTIFUN)

        Get the session key (OSESSKEY)

---> Send 370 bytes - Data packet timestamp=020-12-26 23:52:24.979 Return opi parameter (TTIRPA)

*<--- Received 1207 bytes - Data packet timestamp=020-12-26 23:52:25.108Start of user function (TTIFUN) Generic authentication call (OAUTH)---> Send 11 bytes - Marker packet timestamp=020-12-26 23:52:26.128 One data byte. Hex character sent over to the server: 1*

---> Send 11 bytes - Marker packet timestamp=020-12-26 23:52:26.129

        One data byte.
        Hex character sent over to the server: 2

<--- Received 11 bytes - Marker packet  timestamp=020-12-26 23:52:26.131
        One data byte.
        Hex character sent over to the server: 2

<--- Received 10 bytes - Data packet  timestamp=020-12-26 23:52:26.134
        Data Packet flags:
                End of file

Please notice that the sample_time when I made V$SESSION snapshot is 23:52:25.741. The time corresponds to this generic authentication call (OAUTH) line.
The 'Failed Logon Delay' is self-explanatory as well. Provided you have some auditing in place, it is more likely you will see some transaction calls you mentioned.
I cannot reproduce it with valid connections at the moment, but I guess it can happen too.

On Sat, 26 Dec 2020 at 21:50, Radoulov, Dimitre <> wrote:

> Hello all,
> I noticed that some records in the active session history views report
> user_id = 0 (sys) and machine indicating remote clients which I'm sure
> are not using sys user to connect to the database. In my case the
> Commit/Rollback.
> I suppose these are some internal clean up operations, but I don't
> understand why some of them are associated with remote clients and
> others with the database server.
> Does anybody know why this might be happening?
> Thanks!
> Regards
> Dimitre
> --

Received on Sun Dec 27 2020 - 01:17:30 CET

Original text of this message