What Caused This Wait Event: Using Oracle's wait_event[] tracing

I talked about a new diagnostic event wait_event[] back at OakTableWorld 2014. Oracle introduced this feature in version 12.1. But since there’s only a camera recorded video of that talk , I’ll document some examples here.

Attaching Actions to Wait Events

The new wait_event[] event name allows you to attach actions, like tracing, to wait events. The action runs whenever a wait event ends. It behaves like Oracle’s SQL Trace that writes out trace lines for wait events only when the wait ends.

For example, I could do something silly (but fun) like this:

I just told my session to crash itself whenever a log file sync wait ends in it. The first commit above didn’t crash as it didn’t have any outstanding transaction to commit. So there was no need for a log file sync wait. But the second commit had some changes to persist, so it followed my direction and crashed itself, right after the wait ended.

Augmenting Wait Event Traces

A more practical use for this event is additional tracing. Oracle SQL Trace can write out wait events, their elapsed times and parameters. But in some cases, I also want to know which exact Oracle kernel function caused that wait event, ideally the whole stack backtrace. This would give me more insight into where and why did this wait happen. A full table scan example is below:

When I ran the above query, I saw lots of db file sequential read waits showing up. It was surprising, as I would have expected almost all waits to be multi-block reads for this full table scan. Either db file scattered read or direct path read wait events.

The execution plan confirms that we should be doing a “simple” full table scan throughout the table segment with multiblock reads:

In past I have written about another approach for troubleshooting such surprises using V$SESSTAT metrics 1 2 . Stack tracing is more universal though, but it is a much lower level tool. I use it to “zoom in” when the typical higher-level tools do not provide enough information.

Let’s enable SQL Trace with the added shortstack tracing for the db file sequential read wait event and rerun the earlier query. I also flushed the buffer cache to avoid having all table blocks already cached in the buffer pool.

Now we have one-line stack backtraces (“short stacks”) printed out whenever a db file sequential read wait ends:

Indeed, we do see stack traces printed out after each wait event of interest. If I replace the “<-” with “\n” in one of the traces, I see the following:

Without going too deep into stack-walking topics in this article, you can read the stack from top down. The idea is to just acknowledge low level physical I/O and logical I/O functions that always show up anyway when accessing data blocks, until you reach “higher level” functions that explain why such single block accesses were requested.

The wait event ended somewhere under the ksfd_io function all in the top. 3 Then I continued walking down the list, just acknowledging and skipping the functions that I’d expect to show up anyway, whenever single block buffered physical reads are used. In short, the kcb* functions are about buffer cache, ktr* functions about transactional consistency and kds* ones are about the data layer (the functions that actually navigate to rows in blocks and read required columns).

I expected some of the kcb , ktr , kds functions to show up as usual, but I stopped walking the stack trace once I saw kdsgnp1() in there. The presence of this function in the current stack trace gives us some new information. kdsgnp* functions are about fetching the NEXT row piece for chained and migrated rows (and any columns spilled over to IOT overflow segments).

These additional single block reads that our simple full table scan was causing, come from chained or migrated rows! And since we are just doing a simple, serial SELECT query without any index-driven access, immediate fetching of next rowpieces during the scan very likely means having too wide for a single block chained rows and not just “plain” migration. There are exceptions , as usual.

Let’s confirm what my table looks like:

Oh yeah, no surprise here. Thanks to the CHAR(2000) columns and 8kB block size, every row that has non-NULL values in these columns ends up chained between 2 blocks.

If you know about the table fetch continued row metric in V$SESSTAT , you would be able to systematically troubleshoot row chaining/migration-related issues without needing wait event tracing. But as I said earlier, tracing any wait event , regardless what causes it, is a much more universal tool, with wide coverage. Not all unexpected single block reads are caused by row chaining, as you’ll see below.

Here’s an example of the same full table scan after I had forced serial direct path read scanning to kick in. This time I’ll show you the trace from start:

The first db file sequential read shows a bunch of kte* functions causing it. If you scroll right, you’ll see kteinpscan_int() right under the table scan row source function ( qertbFetch() means TABLE ACCESS FULL Fetch in this case). This single block read right in the beginning of the table scan is done for reading this segment’s extent map and High-Water Mark from the segment header block (block #8034) above, so that Oracle would know which block ranges in the data files to scan through. The remaining two single block reads above are the familiar “get next row piece” reasons I described earlier ( kdsgnp1 ).

But if you continue reading further down in the trace file, there are more reasons, check out this excerpt:

The ktsp functions (Kernel Transaction Space) usually have to do with free space search within a segment - find which blocks below the HWM of a segment still have space for insertion. This is interesting as I am running a simple select query here, not an insert or update, intra-segment free space awareness should not be needed? Before guessing what’s going on, let’s see what exact blocks the block numbers #38915 and #8033 point to in file #7.

I could dump these blocks to trace too, but I’ll use a different technique using just V$ views. As this table’s blocks happen to be in buffer cache due to previous testing, I can query the block class from V$BH :

Apparently, the single block read in the middle of the segment is done against an ASSM 1st level bitmap block. Indeed, my testing table is using Automatic Segment Space Management. Let’s check the second single block I/O too:

Ok, the 2nd I/O is also against an ASSM bitmap block (L2). You may have noticed something intriguing above. The ASSM L2 bitmap block is at block number #8033. But wait a minute, wasn’t the table’s segment header at block #8034, thus making this ASSM block reside before the segment header block in the datafile? The answer is yes , this is how ASSM works, there are always two or more ASSM blocks (L1+L2) stored in the first extent of a segment and the segment header block comes after.

FYI: You can download my 15yr old presentation on Oracle ASSM internals , if you dare :-)

Ok, back to the troubleshooting. Why would my simple full table scan need to do single block I/Os to read ASSM blocks? The extent map and High-Water Mark of a segment are stored in the segment header block. A map with offsets of up to 505 extents can be stored in the segment header with 8kB block size, my table only had 92 extents. If the table had more than 505 extents, then since Oracle 8.0, additional overflow extent map blocks would have been created in the segment as it grows.

Regardless of the extent map layout, in my case we were reading ASSM bitmap blocks , not extent map blocks anyway. The reason why my simple full table scan ends up reading ASSM space metadata is thanks to HWM changes in ASSM. There’s not just one HWM in ASSM, but two - Low High-Water Mark (LHWM) and High High-Water Mark (HHWM). All blocks below LHWM are formatted, so ok to scan, there are no formatted blocks at all above the HHWM and some blocks may be formatted between LHWM and HHWM. In order to know which blocks are formatted and may contain data, my table scan needs to consult the relevant ASSM bitmap blocks.

If you are wondering why such complexity is needed - it’s not really for query speedup. This is designed to spread contention when many concurrent sessions try to insert data and allocate blocks for themselves within a segment. The reason why you typically don’t see such single block reads showing up with buffered table scans, is that a buffered multiblock read will read the ASSM bitmap blocks in from the beginning of each extent as it does its multiblock reads. The ASSM bitmap blocks are read into cache together with regular data blocks under the db file scattered read events you see. With a direct path read , you’d read the block ranges into PGA private memory, but the ASSM space search codepath only knows how to read ASSM bitmap blocks via buffer cache.

Ok, I’ll stop the ASSM-specific content here, I wanted to demo just another scenario where wait event tracing can shed light on hard to explain I/Os or waits.

Note that the wait_event[] actions are independent of SQL Tracing, I just happened to enable both SQL Trace and custom wait event tracing in this example.

Dumping PL/SQL Call Stack on a Wait Event

In the previous section we did some pretty microscopic analysis using Oracle RDBMS kernel call stacks. It is possible to use Oracle’s errorstack() action for also dumping PL/SQL call stack and source code line number info. For example, you can trace where exactly in your stored procedures are all these DBMS_LOCK.SLEEP() waits coming from:

The errorstack trace will also interpret and dump your PL/SQL call stack (in addition to the binary kernel C function call stack). As you see below, it even tells you the source code line number for use with DBA_SOURCE (line #4 in SYSTEM.P):

As dumping the session’s errorstack is a relatively heavy operation, you might not want to trace all occurrences of this event and perhaps just dump it out once in a session:

Note that you have to use the misspelled word occurence in the above syntax for it to work.

Or you could invoke the errorstack dump action only when the wait event’s duration was longer than N milliseconds:

Most of the tracing options are documented in the ORADEBUG DOC command output (you’ll need to run it as SYS). For example, I can list the event filters (for narrowing down when the actions fire) using ORADEBUG DOC EVENT FILTER and drill down deeper from there:

You can see all the options by experimenting with these commands yourself or just go read my ORADEBUG DOC article.

Tracing ALL wait events

So far, we have traced only specific wait events by their name. Oracle allows to also trace all wait events when passing in “all” as the wait event name:

Since I’m tracing all wait events now, I want the trace action to print out the wait event names too. The event argument #5 is a pointer to the event name string, so I’ll have to copy the string in using evargs(5) function. The other arguments are just numeric values, so they can be listed with evargn() .

When running DBMS_LOCK from my session (SQL Trace is not enabled, only the custom wait_event trace), we get the following trace output:

Trace output:

We just built our own, flexible, SQL Trace-like wait event tracing using the Oracle’s diagnostic tracing infrastructure.

The aim of this post was to demonstrate the flexibility of Oracle’s built in diagnostic infrastructure, in the context of augmenting wait events. We looked into how to print out Oracle RDBMS kernel stack traces, PL/SQL stack traces and custom tracing when a wait event of interest completes. We looked into how to fire the diagnostic events only when specific filter conditions match and even how to conditionally crash our session for fun!

As these tracing techniques are undocumented and as some dumps can slow your process down, you should not use these in production as your first tool of choice. You’d still start from things like SQL Monitoring, ASH, SQL Trace and if these techniques are not enough, see how to apply selective additional tracing with as narrow focus as possible. Additionally, you may want to make these trace events turn themselves off automatically, after a few occurrences of the problematic event.

If you want more info about low-level wait event internals and some pretty advanced low-level workings, watch these YouTube videos:

  • My OakTableWorld 2014 talk where I first showed this technique (camera recording)
  • My Hacking session about wait event internals and X$TRACE (screencast)

Detect Chained and Migrated rows in Oracle   ↩︎

Advanced Oracle Troubleshooting Guide: Index Unique Scan Doing Multiblock Reads   ↩︎

Actually, the function dealing with wait event ending (and calling any additional debug/tracing actions) is called kslwtectx() , but the traced function itself is not dumped out by the shortstack() action. It can be printed using the evfunc() trace function.  ↩︎

single task message wait event oracle

  • I am finally close to launching the completely rebuilt 2024 versions of my Linux & AOT classes in my Learning Platform! (Updates to SQL Tuning class in H2 2024): Advanced Oracle SQL Tuning training . Advanced Oracle Troubleshooting training , Linux Performance & Troubleshooting training . Check them out!
  • Get randomly timed updates by email or follow Social/RSS

single-task message

When running single task, this event indicates that the session waits for the client side of the executable.

Wait Time: Total elapsed time that this session spent in the user application

Parameters: None

Scripting on this page enhances content navigation, but does not change the content in any way.

what happens in the single-task message?

  • From : "Martin Busik" <martin.busik@xxxxxxxx>
  • To : <oracle-l@xxxxxxxxxxxxx>
  • Date : Tue, 2 Dec 2008 11:20:51 +0100
  • From: Martin Berger

Other related posts:

  • » what happens in the single-task message? - Martin Busik
  • » Re: what happens in the single-task message? - Martin Berger
  • » RE: what happens in the single-task message? - Martin Busik
  • » Re: what happens in the single-task message? - Niall Litchfield
  • » Previous by Date
  • » Next by Date
  • » Related Posts
  • » View list details
  • » Manage your subscription

暂无图片

  • 2020年openGauss
  • 2022年PolarDB
  • 2023年OceanBase
  • 课程中心 推荐优质内容、热门课程
  • 学习路径 预设学习计划、达成学习目标
  • 知识图谱 综合了解技术体系知识点
  • 课程库 快速筛选、搜索相关课程
  • 视频学习 专业视频分享技术知识
  • 电子文档 快速搜索阅览技术文档
  • SQLRUN 在线数据库即时SQL运行平台
  • 数据库在线实训平台 实操环境、开箱即用、一键连接
  • AWR分析 上传AWR报告,查看分析结果
  • SQL格式化 快速格式化绝大多数SQL语句
  • SQL审核 审核编写规范,提升执行效率
  • PLSQL解密 解密超4000字符的PL/SQL语句
  • OraC函数 查询Oracle C 函数的详细描述
  • 智能助手小墨 关于数据库相关的问题,您都可以问我

暂无图片

Performance tuning library cache lock & single-task message

My colleague suddenly encountered a problem today,a Database becomes very slow , and the a lot of session wait library cache lock event, Let me help him to look. DB env is 10.2.0.4 rac.

at first ,to generate a AWR manually.

Riyaj Shamsudeen wrote in his blog that ” Library cache locks aka parse locks are needed to maintain dependency mechanism between objects and their dependent objects like SQL etc. For example, if an object definition need to be modified or if parse locks are to be broken, then dependent objects objects must be invalidated. This dependency is maintained using library cache locks. For example, if a column is dropped from a table then all SQLs dependent upon the table must be invalidated and reparsed during next access to that object. Library cache locks are designed to implement this tracking mechanism. ”

The wait parameters of library cache lock & pin waits are

  • p1 The address in the memory of the libraray cache handle
  • p2 The memory address of the lock and pin structure
  • p3 is encoded as 10*mode+namespace
  • mode = 3 shared, 5 exclusive The namespaces are
  • 1 Table, procedure & others
  • 2 package body

Find blocker sessions holding the lib cache in RAC

What are the holders waiting for?

what is event ‘single-task message’?

Oracle’s definition of the event: When running single task, this event indicates that the session waits for the client side of the executable. Wait Time: Total elapsed time that this session spent in the user application.

where is the “the client side of the executable” came from? the I check the sql text.

the Db link is worked fine. but blocker session status was ‘KILLED’, it is still here . then try to kill the session again, when the blocker session is gone, the Waiting for the event ‘library cache lock’ has disappeared.

暂无图片

Antonio NAVARRO's Database Blog

Database link and event “single-task message”.

Today I had a problem with a private database link between two databases. The user reports that running a simple “desc [email protected]” doesn’t work.  Currently in the source database are three sessions hung. If we look at that do these sessions, we can see that are waiting for the event single-task message.

foto1

This event usually occurs across the database link connection. We tried to perform a tnsping to check the listener.

foto2

Tnsping command doesn’t reply, so we can determine that the problem is the listener, try perform a lsnrctl status but not responding so we opted to finish the process with the command “kill -9” since we are on unix platform and restart the listener. In the source database the first three sessiones continue unanswered so we kill, in this case from database.

foto3

The kill command reply “ORA-00031: session marked for kill”. The sessions continue but do not die, so we kill them using kill command from Operating System .

Share this:

Leave a comment cancel reply.

' src=

  • Already have a WordPress.com account? Log in now.
  • Subscribe Subscribed
  • Copy shortlink
  • Report this content
  • View post in Reader
  • Manage subscriptions
  • Collapse this bar

Database Networking (MOSC)

MOSC Banner

Discussions

Connections that go over DB Links are randomly getting stuck waiting on single-task message

I have an intermittent problem with sessions hanging waiting on single-task message .

Supposedly this is: When running single task, this event indicates that the session waits for the client side of the executable.

I’m not sure exactly the ‘Client Side’ is in this case.

I think the simple Description is saying ‘Your App’ made a request from the DB, we sent a response back and we are waiting on it.” In other support notes where the issue is the far side of a DB Link connection.

Out App tier is deployed in Cloud Foundry ‘App Containers’. The original thinking was that bouncing those app containers were orphaning these sessions and causing this problem. I have demonstrated that is NOT the case. These sessions are hung HARD and have to be killed from the OS level. As such reinitializing a Cloud Foundry App Container will leave hung sessions with the old ‘Machine Identifier’ listed in Oracle, but they were hung BEFORE the App Container was Bounced.

Howdy, Stranger!

To view full details, sign in to My Oracle Support Community.

Don't have a My Oracle Support Community account? Click here to get started.

Instructions for posting

1. Select a discussion category from the picklist.

2. Enter a title that clearly identifies the subject of your question.

3. In the body, insert detailed information, including Oracle product and version.

Please abide by the Oracle Community guidelines and refrain from posting any customer or personally identifiable information (PI/CI).

Cloud / Fusion customers - Our Cloud community has moved! Please go to Cloud Customer Connect .

New to My Oracle Support Community? Visit our Welcome Center

  • Reset Password
  • SQL DBA Jobs

IT Tutorial IT Tutorial | Oracle DBA | SQL Server, Goldengate, Exadata, Big Data, Data ScienceTutorial

Oracle wait events and their solutions in oracle database.

Mehmet Salih Deveci July 5, 2019 3 Comments

I will explain Oracle Database Wait Events and Their Solutions in this article.

Oracle Database Wait Events

I will describe some of the wait events that cause performance problems in Oracle Databases. You can find the top 5 wait events in the AWR reports. In this article, I will tell you about the most frequently encountered Wait events in AWR reports.

If you don’t know what is the AWR report and how to generate it, read following article before this.

How to Generate AWR ( Automatic Workload Repository ) Report via SQL*Plus, Enterprise Manager and Toad in Oracle

Oracle Wait Events and Their Solutions

Db file sequential read.

Db file sequential read:  This event occurs when a user tries to perform a Physical I/O while waiting for sequential reads from the Buffer cache. This type of situation usually occurs when the data on the table is accessed by using index, not full table scan, as a result of single block reading.

If this event occurs,  possible reasons are wrong index usage, index fragmentation, excessive I/O traffic on specific disks. To Solve this problem, Query should use Right index and fragmented indexes should be defragmented with Rebuild Index operation.

When you encounter this wait event, which appears very frequently in AWR and ADDM reports, we cannot always say that there is a problem. However, if this wait event takes place, if the database have ‘Enqueue’ and Latch Free and they are spending too much time, then database should be monitored

Db file scattered read

Db file scattered read:  This wait event occurs getting multiblock of physical blocks that are not physically close to each other (neighbors) into buffer cache Scattered, or during a full scan to the buffer cache. So Db file scattered read is to read multiple blocks I/O during the fast full scan.

Small tables can be cached to avoid this wait event.

Direct path read

Direct path read:  This event occurs when Oracle Instance query data from the Datafiles asynchronously and puts this data into PGA  instead of Buffer Cache in SGA.

This type of event usually occurs during the use of Temporary ( Temp ) Tablespace in the Sorting operations, during the creation of Lob segments, and when multiple sessions Full table scan in parallel.

In order to solve this problem, the memory should be increased, parallel operations should not be done unless required, and pay attention to Lob segments reads.

DB CPU : This event represents the total time spent of the users’ queries on the CPU.  Oracle’s Background processes (SMON, PMON ..) are not included in this total time.

If this value is high, it means that the Oracle instance spends most of the time on the CPU. To reduce this wait event, the SQLs in the SQL ordered by CPU section in the AWR report must be TUNE.

Log file sync

Log file sync:  This event is known as the time lost as a result of the LGWR process waiting while users initiate a Transaction Commit or Rollback.

If this wait event is available continuously, I/O performance of the LGWR process is probably poor, or Commit is coming too often by the application. The solution to this problem is not to commit too much, if necessary, and to examine the I/O performance of the disk on which the Redo log files are located, and to use a high performance disk such as an SSD disk if necessary.

Enq: TX – row lock contention

Enq: TX – row lock contention:   This type of event occurs when a user session is trying to update or delete a row held by another session, which is an application design problem. Normally, when a transaction is finished, commit or rollback must be executed to release related rows.

The solution to this problem is that if the session that holds the row is active, then execute commit statement, if it is not active, kill the session or execute rollback the session.

ARCH wait on SENDREQ:  This wait event is the total time taken by the Archiver Processes to archive the Standby in the Dataguard and to write these archives to the local disks.

The main reason why this value is high is that the archives sent to the Standby side arrive late due to the network. To solve this problem, it is necessary to optimize the Network and set the DEFAULT_SDU_SIZE parameter in the sqlnet.ora file to an optimized value (32767).

Gc current block busy:   This wait event occurs between the nodes of the Cluster database ( Real Application Cluster ). When a transaction requests a block, that request sent to the master instance. Normally, this request is performed by a cache fusion.

However, in some cases, this block transfer is delayed because the corresponding instance is held by the other instance or because the corresponding transaction records cannot be written to the redo logs immediately, in which case this wait event is triggered.

This can be solved by tune the wait event Log Writer process or Solving network problem between Cluster nodes.

Gc cr block busy wait:  This wait event occurs like the gc current block busy wait event above. The only difference is that while the above event is running in current mode, this wait event runs in CR mode. This can be solved by tune the wait event Log Writer process.

Do you want to learn Oracle Database Performance Tuning detailed, then Click this link.

About mehmet salih deveci.

single task message wait event oracle

It is very useful for learning. If possible, please explain how to identify performance issues by using AWR report.

single task message wait event oracle

Read these article series to identify performance issues by using AWR report.

https://ittutorial.org/how-to-analyze-an-awr-report-in-oracle-4-top-sql/

single task message wait event oracle

Excellent stuff for DBA’s, thank you sir. Keep posting this kind of stuff.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Zed DBA's Oracle Blog

The oracle dba specialist – ocm, ocp, oce, ocs, ace, session using a database link hangs on “sql*net more data from dblink”.

I have a client who recently move a database server from on-premise to a Cloud provider.  A database on this database server had a database link to their E-business database in the Oracle Cloud.  Since the move, any sessions in the database that use the database link to the E-business database would hang if the query was to return large dataset.

Below is selecting from dual over the database link that worked:

But selecting from a table hangs:

The session in the source database shows the wait “ SQL*Net more data from dblink ”:

The session in the target database shows the wait “SQL*Net message from client” :

I traced the source session and could see the session hangs waiting for more data from the target (EBS) database:

After raising a SR with My Oracle Support (MOS) for the database we manage and for the one Oracle manage in the Oracle Cloud, it was concluded the package size (Session Data Unit) was larger then the allowable for a network component between the two databases.  They referred to MOS note:

Query on “bigtable” from remote Client hangs (certain queries or fields) (Doc ID 2104257.1 )

“SYMPTOMS

Certain queries are hanging when run from some remote Clients.  However, other (smaller) queries are successful.

This is especially evident on queries that require more than 2kb of data to be returned. Some examples:

select * from v$database; –> hangs select count(*) from v$database; –> works

DESCRIBE with large data results –> hangs DESCRIBE with small data results –> works

This might also show up with Database Links (DBLINK) as well.

A Network “security” device or setting (possibly local especially on a Microsoft Windows machine) is preventing or “altering” larger TCP packets from being transported across the network. This in turn is causing the Client to wait on the Server for the data from the query, and the Server to wait on the Client (which thinks part of the packet is still on the way).

1. Check for settings like the DF (“Don’t Fragment”) bit being set. 2. Check for ALG SQL settings being enabled.

*Note: these causes are all external to Oracle so provided only as potential causes.

Workaround ~~~~~~~~~ As a workaround (or test to prove this is or is not the issue) lower the SQL*Net SDU from the default size of 8192 to 1400 (see reference below for more details on this setting):

1. Add the following single line to the sqlnet.ora file on BOTH ends of the communication: DEFAULT_SDU_SIZE = 1400

2. Restart the Listener(s) servicing the Database in question, make a new connection from the Client, and test the query that was hanging.

3. If this corrects the issue and allows queries to complete, then there is a network / system device or setting causing fragmentation, detention, or alteration of SQL packets mid-stream.”

Oracle Support set the SDU in the sqlnet.ora file on the target database server: DEFAULT_SDU_SIZE = 1400

More info on DEFAULT_SDU_SIZE can be found here:

Database Net Services Reference -> 5 Parameters for the sqlnet.ora File -> DEFAULT_SDU_SIZE

And then restarted the listener.  I did the same for the source database server and then the session no longer hanged 🙂 :

28/08/2018 The issue wasn’t resolved and the MTU of the network cards on both the source and target servers was also changed to 1400.  It could possibly been resolved by reducing the SDU further but it was decided to change the MTU on network cards.  In most cases the SDU change will fix the issue, but otherwise the MTU on network card can also resolve the issue as in this case.

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Zed DBA (Zahid Anwar)

Share this:

4 thoughts on “ session using a database link hangs on “sql*net more data from dblink” ”.

Hello Zed The post is good. Keep it up

i have similar issue we are trying to migrate the data from one db to another via db link. when the data set is large like 30M or so it will complete fetching data over the db link and hten insert in the calling db. Now it again does a query over the same dbl ink to get next set of 30 M and it will hang. Session needs to be killed. But if i end the session and call the next 30M in different script it will work. What is reason for that ? any workarounds ?

It’s hard to say without knowing the exact details. I’d say check the wait events on both source and target. Use tracing if necessary like I did. Failing this, raise an SR with Oracle Support to assist you.

Hope that helps

Kind Regards

Leave a comment Cancel reply

' src=

  • Already have a WordPress.com account? Log in now.
  • Subscribe Subscribed
  • Copy shortlink
  • Report this content
  • View post in Reader
  • Manage subscriptions
  • Collapse this bar

Skip Headers

Wait Event Descriptions

This section describes some of the more common Oracle events in more detail.

alter system set dispatchers

A session has issued a statement ALTER SYSTEM SET DISPATCHERS = string and is waiting for the dispatchers to get started.

Wait Time: The session will wait 1 / 100 of a second and check to see if the new dispatchers have started else the session will wait again

batched allocate scn lock request

A session is waiting on another process to allocate a system change number (SCN). If the foreground timed out waiting on a process to get the SCN, the foreground will get the SCN.

Wait Time: The wait time is 1 second on the assumption that an SCN allocation should normally need much less than that

Parameters: None

BFILE check if exists

The session waits to check if an external large object (LOB) exists.

Wait Time: The total elapsed time for the exists call

BFILE check if open

The session waits for an external large object (LOB) to open.

Wait Time: The total elapsed time for the isopen call

BFILE closure

The session waits for an external large object (LOB) to close.

Wait Time: The total elapsed time for the close call

BFILE get length

The session waits on a call to check the size of an external large object (LOB).

Wait Time: The total elapsed time for the call to check the LOB size

BFILE get name object

The session waits on a call to find or generate the external name of a external large object.

Wait Time: The total elapse time for make external file name to complete

BFILE get path object

The session is waiting on a call to find or generate the external path name of an external large object (LOB).

Wait Time: The total elapsed time for make external path to complete

BFILE internal seek

The session waits for a positioning call within the external large object (LOB) to complete.

Wait Time: The total elapse time for the seek to complete

The session waits for a read from a external large object (LOB) to complete.

Wait Time: The total elapse time for the read to complete

buffer busy waits

Wait until a buffer becomes available. This event happens because a buffer is either being read into the buffer cache by another session (and the session is waiting for that read to complete) or the buffer is the buffer cache, but in a incompatible mode (that is, some other session is changing the buffer).

Wait Time: Normal wait time is 1 second. If the session was waiting for a buffer during the last wait, then the next wait will be 3 seconds.

buffer deadlock

Oracle does not really wait on this event; the foreground only yields the CPU. Thus, the chances of catching this event are very low. This is not an application induced deadlock, but an assumed deadlock by the cache layer. The cache layer cannot get a buffer in a certain mode within a certain amount of time.

Wait Time: 0 seconds. The foreground process only yields the CPU and will usually be placed at the end of the CPU run queue.

buffer for checkpoint

The buffer could not be checkpointed, because some process is modifying it. This means that after the wait, the DBWR will scan the whole buffer cache again. This could happen during a database close or after a user does a local checkpoint. During this situation the database cannot be closed.

Wait Time: 1 second

buffer latch

The session waits on the buffer hash chain latch. Primarily used in the dump routines.

buffer read retry

This event occurs only if the instance is mounted in shared mode (Oracle Real Application Cluster). During the read of the buffer, the contents changed. This means that either:

The version number, dba, or the incarnation and sequence number stored in the block no longer match

The checksum on the block does not match the checksum in the block

The block will be re-read (this may fail up to 3 times), then corruption is assumed and the corrupt block is dumped in the trace file.

Wait Time: The wait time is the elapsed time of the read

checkpoint completed

A session waits for a checkpoint to complete. This could happen, for example, during a close database or a local checkpoint.

Wait Time: 5 seconds

checkpoint range buffer not saved

During a range checkpoint operation a buffer was found that was not saved or written. Either:

The session will wait on this event if the write batch is empty and it is the first time that the session waited on this event in the range checkpoint operation

The current range checkpoint operation will be aborted and a new one will be started to complete the operation

Wait Time: 10 milliseconds

control file parallel write

This event occurs while the session is writing physical blocks to all control files. This happens when:

The session starts a control file transaction (to make sure that the control files are up to date in case the session crashes before committing the control file transaction)

The session commits a transaction to a control file

Changing a generic entry in the control file, the new value is being written to all control files

Wait Time: The wait time is the time it takes to finish all writes to all control files

control file sequential read

Reading from the control file. This happens in many cases. For example, while:

Making a backup of the controlfiles

Sharing information (between instances) from the controlfile

Reading other blocks from the controlfiles

Reading the header block

control file single write

This wait is signaled while the control file's shared information is written to disk. This is an atomic operation protected by an enqueue (CF), so that only one session at a time can write to the entire database.

Wait Time: The wait time is the elapsed time of the write

conversion file read

This event occurs during the creation of a Version 7 controlfile as part of converting a database to Version 7 from Version 6.

db file parallel read

This happens during recovery. Database blocks that need to be changed as part of recovery are read in parallel from the database.

Wait Time: Wait until all of the I/Os are completed

db file parallel write

This event occurs in the DBWR. It indicates that the DBWR is performing a parallel write to files and blocks. The parameter requests indicates the real number of I/Os that are being performed. When the last I/O has gone to disk, the wait ends.

db file scattered read

Similar to db file sequential read , except that the session is reading multiple data blocks.

Wait Time: The wait time is the actual time it takes to do all of the I/Os

db file sequential read

The session waits while a sequential read from the database is performed. This event is also used for rebuilding the control file, dumping datafile headers, and getting the database file headers.

Wait Time: The wait time is the actual time it takes to do the I/O

db file single write

This event is used to wait for the writing of the file headers.

DFS db file lock

This event occurs only for the DBWR in the Oracle Real Application Cluster. Each DBWR of every instance holds a global lock on each file in shared mode. The instance that is trying to offline the file will escalate the global lock from shared to exclusive. This signals the other instances to synchronize their SGAs with the controlfile before the file can be taken offline. The name of this lock is DF (see Appendix D, " Oracle Enqueue Names" for more information).

Wait Time: 1 second in loop. The DBWR is waiting in a loop (sleep, check) for the other instances to downgrade to NULL mode. During this time, the DBWR cannot perform other tasks such as writing buffers.

DFS lock handle

The session waits for the lock handle of a global lock request. The lock handle identifies a global lock. With this lock handle, other operations can be performed on this global lock (to identify the global lock in future operations such as conversions or release). The global lock is maintained by the DLM.

Wait Time: The session waits in a loop until it has obtained the lock handle from the DLM. Inside the loop there is a wait of 0.5 seconds.

The session needs to get the lock handle.

direct path read

During Direct Path operations the data is asynchronously read from the database files. At some stage the session needs to make sure that all outstanding asynchronous I/O have been completed to disk. This can also happen if during a direct read no more slots are available to store outstanding load requests (a load request could consist of multiple I/Os).

Wait Time: 10 seconds. The session will be posted by the completing asynchronous I/O. It will never wait the entire 10 seconds. The session waits in a tight loop until all outstanding I/Os have completed.

direct path write

During Direct Path operations, the data is asynchronously written to the database files. At some stage the session needs to make sure that all outstanding asynchronous I/O have been completed to disk. This can also happen if, during a direct write, no more slots are available to store outstanding load requests (a load request could consist of multiple I/Os).

dispatcher shutdown

During shutdown immediate or normal, the shutdown process must wait for all the dispatchers to shutdown. As each dispatcher is signaled, the session that causes the shutdown is waits on this event until the requested dispatcher is no longer alive.

dispatcher timer

This basically means that the dispatcher is idle and waiting for some work to arrive.

Wait Time: 60 seconds

duplicate cluster key

It is possible for a race condition to occur when creating a new cluster key. If it is found that another process has put the cluster key into the data/index block, then the session waits and retries. The retry should then find a valid cluster key.

Wait Time: 0.01 seconds

The session is waiting for a local enqueue. The wait is dependent on the name of the enqueue (see Appendix D, " Oracle Enqueue Names" ).

Wait Time: Depends on the enqueue name

file identify

The time it takes to identify a file so that it can be opened later.

The time it takes to open the file.

free buffer waits

This will happen if:

All buffer gets have been suspended. This could happen when a file was read-only and is now read-write. All the existing buffers need to be invalidated since they are not linked to lock elements (needed when mounted parallel (shared)). So cache buffers are not assigned to data block addresses until the invalidation is finished.

The session moved some dirty buffers to the dirty queue and now this dirty queue is full. The dirty queue needs to be written first. The session will wait on this event and try again to find a free buffer

This also happens after inspecting free buffer inspected buffers. If no free buffer is found, Oracle waits for one second, and then tries to get the buffer again (depends on the context). For more information, see free buffer inspected .

Wait Time : 1 second

free global transaction table entry

The session is waiting for a free slot in the global transaction table (used by the Distributed Database option). It will wait for 1 second and try again.

free process state object

Used during the creation of a process. The session will scan the process table and look for a free process slot. If none can be found, PMON is posted to check if all the processes currently in the process table are still alive. If there are dead processes, then PMON will clean them and make the process slot available to new processes. The waiting process will then rescan the process table to find the new slot.

global cache busy

The session waits to convert a buffer from Shared Current to Exclusive Current status.

global cache lock cleanup

PMON is waiting for an LCK process to cleanup the lock context after a foreground process died while doing a global cache lock operation.

global cache freelist wait

All releasable locks are used and a new one has been requested. To make a resource element available, a resource element is pinged.

Wait Time: The duration of the resource get operation to ping the resource element

global cache null to s

The session waits for a resource convert from NULL to SHARED mode on the block identified by file# and block#.

global cache null to x

The session waits for a resource convert from NULL to EXCLUSIVE mode on the block identified by file# and block#.

global cache open s

The session waits for a resource get in SHARED mode on the block identified by file# and block#.

global cache open x

The session waits for a resource get in EXCLUSIVE mode on the block identified by file# and block#.

global cache s to x

The session waits for a resource convert from SHARED to EXCLUSIVE mode on the block identified by file# and block#.

inactive session

This event is used for two purposes:

Switching sessions

If a time-out period has been specified, then wait that amount of time for the session to be detached.

Killing sessions

From either KILL SESSION or internal request. Having posted a session that it should kill itself, wait for up to 1 minute for the session to terminate.

inactive transaction branch

The session waits for a transaction branch that is currently used by another session.

index block split

While trying to find an index key in an index block, Oracle noticed that the index block was being split. Oracle will wait for the split to finish and try to find the key again.

Wait Time: The session will yield the CPU, so there is no actual waiting time

instance recovery

The session waits for SMON to finish the instance, transaction recovery, or sort segment cleanup.

Wait Time: The wait time can vary and depends on the amount of recovery needed

instance state change

The session waits for SMON to enable or disable cache or transaction recovery. This usually happens during ALTER DATABASE OPEN or CLOSE .

Wait Time: Wait time depends on the amount of time the action takes (that is, the amount of recovery needed)

The session waits for an I/O to complete or it waits for a slave process to become available to submit the I/O request. This event occurs on platforms that do not support asynchronous I/O.

Wait Time: 50 milliseconds

kcl bg acks

The session waits for the background LCK process(es) to finish what they are doing. For example:

Lock recovery

Initializing the locks (start up)

Finalizing the locks (shut down)

Wait Time: 10 seconds

latch activity

This event is used as part of the process of determining whether a latch needs to be cleaned.

Wait Time: 0.05 to 0.1 seconds

The process waits for a latch that is currently busy (held by another process).

Wait Time: The wait time increases exponentially and does not include spinning on the latch (active waiting). The maximum wait time also depends on the number of latches that the process is holding. There is an incremental wait of up to 2 seconds.

library cache load lock

The session tries to find the load lock for the database object so that it can load the object. The load lock is always obtained in Exclusive mode, so that no other process can load the same object. If the load lock is busy the session will wait on this event until the lock becomes available.

Wait Time: 3 seconds (1 second for PMON)

library cache lock

This event controls the concurrency between clients of the library cache. It acquires a lock on the object handle so that either:

One client can prevent other clients from accessing the same object

The client can maintain a dependency for a long time (for example, no other client can change the object)

This lock is also obtained to locate an object in the library cache.

library cache pin

This event manages library cache concurrency. Pinning an object causes the heaps to be loaded into memory. If a client wants to modify or examine the object, the client must acquire a pin after the lock.

lock manager wait for remote message

The lock manager waits for a message from a remote lock manager in the same configuration.

Wait Time: The elapsed time of the wait

log buffer space

Waiting for space in the log buffer because the session is writing data into the log buffer faster than LGWR can write it out. Consider making the log buffer bigger if it is small, or moving the log files to faster disks such as striped disks.

Wait Time: Usually 1 second, but 5 seconds if it is waiting for a Switch Logfile to complete

log file parallel write

Writing redo records to the redo log files from the log buffer.

Wait Time: Time it takes for the I/Os to complete. Even though redo records are written in parallel, the parallel write is not complete until the last I/O is on disk.

log file sequential read

Waiting for the read from this logfile to return. This is used to read redo records from the log file.

Wait Time: Time it takes to complete the physical I/O (read)

log file single write

Waiting for the write to this logfile to complete. This event is used while updating the header of the logfile. It is signaled when adding a log file member and when incrementing sequence numbers.

Wait Time: Time it takes for the physical I/O (write) to complete

log file switch (archiving needed)

Waiting for a log switch because the log that the LGWR will be switching into has not been archived yet. Check the alert file to make sure that archiving has not stopped due to a failed archive write. To speed archiving, consider adding more archive processes or putting the archive files on striped disks.

log file switch (checkpoint incomplete)

Waiting for a log switch because the session cannot wrap into the next log. Wrapping cannot be performed because the checkpoint for that log has not completed.

log file switch (clearing log file)

Waiting for a log switch because the log is being cleared due to a CLEAR LOGFILE command or implicit clear logfile executed by recovery.

log file switch completion

Waiting for a log switch to complete.

log file sync

When a user session commits, the session's redo information needs to be flushed to the redo logfile. The user session will post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session.

Wait Time: The wait time includes the writing of the log buffer and the post.

log switch/archive

Used as part of the ALTER SYSTEM ARCHIVE LOG CHANGE scn statement. The session waits for the current log from all open threads to be archived.

Wait Time: Wait for up to 10 seconds

on-going SCN fetch to complete

Another session is fetching the SCN (system change number). This session waits for the other session finish fetching the SCN.

pending global transaction(s)

This event should happen only during testing. The session waits for pending transactions to clear.

Wait Time: 30 seconds

The session waits for a message to be received on the pipe or for the pipe timer to expire.

Wait Time: There is a 5 second wake up (check) and the pipe timer set by the user

The session waits for the pipe send timer to expire or for space to be made available in the pipe.

Wait Time: There is the 5 second wakeup (check) and the user-supplied timeout value

PL/SQL lock timer

This event is called through the DBMSLOCK.SLEEP procedure or USERLOCK.SLEEP procedure. This event will most likely originate from procedures written by a user.

Wait Time: The wait time is in hundredths of seconds and is dependent on the user context

This is the main wait event for PMON. When PMON is idle, it is waiting on this event.

Wait Time: Up to 3 seconds, if not posted before

process startup

Wait for a shared server, Dispatcher, or other background process to start.

Wait Time: Wait up to 1 second for a background process to start. If timed out, then re-wait until 5 minutes have passed and signal an error. If the process has started, the event will acknowledge this.

PX dequeue wait

The process is waiting for a message during a parallel execute.

Wait Time: The wait time depends on how quickly the message arrives. Wait times can vary, but it will normally be a short period of time.

PX qref latch

Each parallel execution process has a parallel execution qref latch, which needs to be acquired before the queue buffers can be manipulated.

Wait Time: Wait up to 1 second

PX server shutdown

During normal or immediate shutdown the parallel execution slaves are posted to shutdown cleanly. If any parallel execution slaves are still alive after 10 seconds, they are killed.

Wait Time: Wait up to 0.5 seconds

PX signal server

This event occurs only in Exclusive mode. The query coordinator is signalling the Query Slaves that an error has occurred.

Wait Time: 0.5 seconds

queue messages

The session is waiting on an empty OLTP queue (Advanced Queuing) for a message to arrive so that the session can dequeue that message.

Wait Time: The amount of time that the session wants to wait is determined by the parameter wait time

rdbms ipc message

The background processes (LGWR, DBWR, LMS0) use this event to indicate that they are idle and are waiting for the foreground processes to send them an IPC message to do some work.

Wait Time: Up to 3 seconds. The parameter timeout shows the true sleep time.

rdbms ipc message block

This event indicates that all message blocks are in use and that the session had to wait for a message block to become available.

Wait Time: Wait up to 60 seconds

rdbms ipc reply

This event is used to wait for a reply from one of the background processes.

Wait Time: The wait time is specified by the user and is indicated by the parameter timeout .

Defined but not used by the code.

row cache lock

The session is trying to get a data dictionary lock.

Wait Time: Wait up to 60 seconds.

scginq AST call

Called by the session to find the highest lock mode that is held on a resource.

Wait Time: Wait up to 0.2 seconds, but the wait will continue until the NULL mode Acquisition AST has fired.

single-task message

When running single task, this event indicates that the session waits for the client side of the executable.

Wait Time: Total elapsed time that this session spent in the user application

This is the main idle event for SMON. SMON will be waiting on this event most of the time until it times out or is posted by another process.

Wait Time: 5 minutes (300 seconds)

SQL*Net break/reset to client

The server sends a break or reset message to the client. The session running on the server waits for a reply from the client.

Wait Time: The actual time it takes for the break or reset message to return from the client

SQL*Net break/reset to dblink

Same as SQL*Net break/reset to client , but in this case, the break/reset message is sent to another server process over a database link.

Wait Time: The actual time it takes for the break or reset message to return from the other server process

SQL*Net message from client

The server process (foreground process) waits for a message from the client process to arrive.

Wait Time: The time it took for a message to arrive from the client since the last message was sent to the client

SQL*Net message from dblink

The session waits while the server process (foreground process) receives messages over a database link from another server process.

Wait Time: The time it took for a message to arrive from another server (foreground process) since a message was sent to the other foreground process.

SQL*Net message to client

The server (foreground process) is sending a message to the client.

Wait Time: The actual time the send takes

SQL*Net message to dblink

The server process (foreground process) is sending a message over a database link to another server process.

SQL*Net more data from client

The server is performing another send to the client. The previous operation was also a send to the client.

Wait Time: The time waited depends on the time it took to receive the data (including the waiting time)

SQL*Net more data from dblink

The foreground process is expecting more data from a data base link.

Wait Time: The total time it takes to read the data from the database link (including the waiting time for the data to arrive)

SQL*Net more data to client

The server process is sending more data/messages to the client. The previous operation to the client was also a send .

Wait Time: The actual time it took for the send to complete

SQL*Net more data to dblink

The event indicates that the server is sending data over a database link again. The previous operation over this database link was also a send .

Wait Time: The actual time it takes to send the data to the other server

switch logfile command

The session waits on the user command SWITCH LOGFILE to complete.

timer in sksawat

The session waits for the Archiver (ARCH) asynchronous I/O to complete.

transaction

Wait for a blocking transaction to be rolled back. Continue waiting until the transaction has been rolled back.

The session waits to see if there are any transactions that have been started but do not have a Rollback Segment associated with them.

undo segment extension

The undo segment is being extended or shrunk. The session must wait until the operation on the undo segment has finished.

undo segment recovery

PMON is rolling back a dead transaction. The wait continues until rollback finishes.

Wait Time: 3 seconds

undo segment tx slot

Wait for a transaction slot to become available within the selected rollback segment. Continue waiting until the slot is available.

virtual circuit status

The session waits for a virtual circuit to return a message type indicated by status .

WMON goes to sleep

WMON is the UNIX-specific Wait Monitor, that can be used to reduce the number of system calls related to setting timers for posting or waiting in Oracle. You need to set an initialization parameter that enables the WMON process.

Wait Time: Depends on the next timeout

write complete waits

The session waits for a buffer to be written. The write is caused by normal aging or by a cross-instance call.

writes stopped by instance recovery or database suspension

The session is blocked until the instance that started Instance Recovery is finished.

  • Install App

Oracle Database Discussions

For appeals, questions and feedback, please email [email protected]

single-task message event

single task message wait event oracle

IMAGES

  1. PPT

    single task message wait event oracle

  2. PPT

    single task message wait event oracle

  3. PPT

    single task message wait event oracle

  4. Understanding the Oracle db file sequential read Wait Event

    single task message wait event oracle

  5. Oracle database wait events

    single task message wait event oracle

  6. [Solved] SQL*Net message from dblink wait event in Oracle

    single task message wait event oracle

VIDEO

  1. || MESSAGE 😭❤️

  2. Oracle Workflow

  3. What is Cache Buffer chain Wait event

  4. How to use Event Triggers in Oracle Fusion || Applstar Technologies

  5. What is Row Cache object Latch Wait event.

  6. Oracle Package and Exception Handling in PLSQL

COMMENTS

  1. "single-task message wait event" what's the meaning of

    2 comments 2,148 views Hello All , Someone knows what's the meaning of this wait event "single-task message" ? The users reported performance troubles, everything is fine, except for this event appearing some t...

  2. Oracle Wait Events

    Oracle Wait Events The V$SESSION_WAIT view displays the events for which sessions have just completed waiting or are currently waiting. The V$SYSTEM_EVENT displays the total number of times all the sessions have waited for the events in that view. The V$SESSION_EVENT is similar to V$SYSTEM_EVENT, but displays all waits for each session.

  3. Descriptions of Wait Events

    Release 23 Database Reference C.3 Descriptions of Wait Events This section provides detailed descriptions for those wait events of greatest interest. Where appropriate, pointers are provided to further information elsewhere in Oracle Database documentation.

  4. Wait Events and Parameters

    The following wait events are present in the Oracle Database. The columns P1, P2, and P3 represent parameters for the wait event. ... select wait : single-task message : slave exit: nalive: sleeptime: loop: slave shutdown wait : slave TJ process wait : smon timer: sleep time: failed : sort segment request : SQL*Net break/reset to client:

  5. single-task message

    Oracle single-task message single-task message Short Description When running single task, this event indicates that the session waits for the client side of the executable. Search online If this article doesn't have the information you need you can try searching online. Remember, you can contribute suggestions to this page.

  6. What Caused This Wait Event: Using Oracle's wait_event[] tracing

    Attaching Actions to Wait Events. The new wait_event [] event name allows you to attach actions, like tracing, to wait events. The action runs whenever a wait event ends. It behaves like Oracle's SQL Trace that writes out trace lines for wait events only when the wait ends. For example, I could do something silly (but fun) like this:

  7. single-task message

    single-task message When running single task, this event indicates that the session waits for the client side of the executable. Wait Time: Total elapsed time that this session spent in the user application Parameters: None Previous Page Page 2654 of 2693 English

  8. Oracle Wait Events, 3 of 5

    The following wait events are present in the Oracle database server. The columns P1, P2, and P3 represent parameters for the wait event. ... event # wait time. select wait. single-task message. slave exit. nalive. sleeptime. loop. slave shutdown wait. slave TJ process wait. ... wait for message ack. wait for name service busy. wait for possible ...

  9. what happens in the single-task message?

    what happens in the single-task message? From: "Martin Busik" <martin.busik@xxxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Date: Tue, 2 Dec 2008 11:20:51 +0100

  10. Performance tuning library cache lock & single-task message

    what is event 'single-task message'? Oracle's definition of the event: When running single task, this event indicates that the session waits for the client side of the executable. Wait Time: Total elapsed time that this session spent in the user application. where is the "the client side of the executable" came from? the I check the ...

  11. Database link and event "single-task message"

    If we look at that do these sessions, we can see that are waiting for the event single-task message. This event usually occurs across the database link connection. We tried to perform a tnsping to check the listener. Tnsping command doesn't reply, so we can determine that the problem is the listener, try perform a lsnrctl status but not ...

  12. Connections that go over DB Links are randomly ...

    Supposedly this is: When running single task, this event indicates that the session waits for the client side of the executable. I'm not sure exactly the 'Client Side' is in this case. I think the simple Description is saying 'Your App' made a request from the DB, we sent a response back and we are waiting on it."

  13. Oracle Wait Events and Their Solutions in Oracle Database

    Small tables can be cached to avoid this wait event. Direct path read . Direct path read: This event occurs when Oracle Instance query data from the Datafiles asynchronously and puts this data into PGA instead of Buffer Cache in SGA. This type of event usually occurs during the use of Temporary ( Temp ) Tablespace in the Sorting operations, during the creation of Lob segments, and when ...

  14. Oracle Wait Events, 5 of 5

    Parameters: BFILE get length The session waits on a call to check the size of an external large object (LOB). Wait Time:The total elapsed time for the call to check the LOB size. Parameters: BFILE get name object The session waits on a call to find or generate the external name of a external large object.

  15. Session using a database link hangs on "SQL ...

    2. Restart the Listener (s) servicing the Database in question, make a new connection from the Client, and test the query that was hanging. 3. If this corrects the issue and allows queries to complete, then there is a network / system device or setting causing fragmentation, detention, or alteration of SQL packets mid-stream.".

  16. Ultrp.sql taking more time to compile the invalid APP objects

    Symptoms. UTLRP script taking more time to compile application related objects. From hang analyzer I can see below symptoms: Chains most likely to have caused the hang: [a] Chain 1 Signature: 'single-task message'<='library cache lock' >>>>>>>>>> single-task message event causing the issue. Chain 1 Signature Hash: 0x7f5164c9.

  17. Descriptions of Wait Events

    Release 19 Database Reference C.3 Descriptions of Wait Events This section provides detailed descriptions for those wait events of greatest interest. Where appropriate, pointers are provided to further information elsewhere in Oracle Database documentation.

  18. Troubleshooting High Waits for 'Reliable Message'

    (Doc ID 2017390.1) Last updated on OCTOBER 02, 2023 Applies to: Oracle Database Backup Service - Version N/A and later Oracle Database Cloud Exadata Service - Version N/A and later Oracle Database Cloud Service - Version N/A and later Oracle Database - Enterprise Edition - Version 11.1.0.6 and later

  19. Descriptions of Wait Events

    Oracle does not really wait on this event; the foreground only yields the CPU. ... C.3.162 single-task message When running single task, this event indicates that the session waits for the client side of the executable. Wait Time: Total elapsed time that this session spent in the user application ...

  20. Wait Event Descriptions

    Wait Time: The wait time is 1 second on the assumption that an SCN allocation should normally need much less than that Parameters: None BFILE check if exists The session waits to check if an external large object (LOB) exists. Wait Time: The total elapsed time for the exists call BFILE check if open

  21. single-task message event

    Sign In Oracle Database Discussions Go back New Post single-task message event 345256 Oct 14 2002 does anyone know when "single-task message" event come out? i am using jdbc connect to oracle 9i. Post Details Locked on Nov 11 2002 Added on Oct 14 2002 #general-database-discussions 0 comments 167 views --- --- Resources for Careers Developers