从 v$datafile 查找表名。姓名栏

发布于 2024-11-28 16:43:15 字数 318 浏览 1 评论 0原文

当您查看等待事件(即使用 Toad)时,您会看到一个 file# 参数。 我怎样才能获得更多有用的信息作为表名。

是否有可能知道该表读取的记录数?

在另一个论坛中我发现了这个建议,但它似乎不起作用。

select segment_name
from dba_extents ext
where ext.file_id = 828
            and 10711 between ext.block_id and ext.block_id + ext.blocks - 1
            and rownum = 1

When you look at wait events (i.e. with Toad), you see a file# parameter.
How can I get more useful information as the table name.

Is it possible to know even the number of records that are read by that table?

In another forum I found this advice, but it doesn't seem to work.

select segment_name
from dba_extents ext
where ext.file_id = 828
            and 10711 between ext.block_id and ext.block_id + ext.blocks - 1
            and rownum = 1

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

东风软 2024-12-05 16:43:15

让我们谈谈文件、块、段和范围。

段是存储的数据库对象。它可以是表、索引、(子)分区、簇或 LOB。大多数情况下,您会对表和索引感兴趣。

段由范围组成。如果将段视为一本书,那么范围就是一章。一个段(通常)至少以一个范围开始。当它需要存储更多数据并且现有范围没有空间时,它会向段添加另一个范围。

范围位于数据文件中。数据文件可以有很多范围,每个范围从文件中的不同点开始并具有一定的大小。您可能有 15 个块的范围,从文件 1 的块 10 开始。

等待事件应标识文件和块(和行)。如果您的等待事件针对文件 #1 和块 12,您将转到 USER_EXTENTS(或 DBA_EXTENTS)并查找文件#1 中的范围,其中 12 位于起始块位置和起始块位置加上块数之间。因此块 12 将位于起始块 10 和结束块 25 之间(起始加上大小)。

一旦确定了范围,就可以将其跟踪回其父段(USER_SEGMENTS / DBA_SEGMENTS),这将为您提供表/索引名称。


理论上的 SQL 如下:

select username, sid, serial#, 
       row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#,
       ext.*
from v$session s
     join dba_extents ext on ext.file_id = row_wait_file#
     and row_wait_block# between ext.block_id and ext.block_id + ext.blocks - 1
where username = 'HR'
and status = 'ACTIVE'

对于这个 SQL,我故意阻止了一个会话,以便它等待行锁。

828是一个相当大的文件ID。这并非不可能,但很不寻常。从 DBA_DATA_FILES 中进行选择,看看是否有这样的文件。如果没有,并且您只有几个文件,请查看与“10711 between ext.block_id and ext.block_id + ext.blocks - 1”条件(不带文件 ID)匹配的所有对象。您应该能够从那里找到可能的候选人。

例外情况是问题出在临时段上。由于这些在操作结束时被丢弃,因此没有记录永久对象。在这种情况下,表/索引的“名称”不适用,您需要以另一种方式解决任何性能问题(例如,查看 SQL 及其解释计划,并确定使用大量临时空间是否正确) 。

Let's talk files, blocks, segments and extents.

A segment is a database object that is stored. It may be a table, index, (sub)partition, cluster or LOB. Mostly you'll be interested in tables and indexes.

A segment is made up of extents. If you think of a segment as a book, an extent is a chapter. A segment (generally) starts with at least one extent. When it needs to store more data and it doesn't have room in the existing extents, it adds another extent to the segment.

An extent lives in a datafile. A datafile can have lots of extents each starting at a different point in the file and having a size. You may have one extent of 15 blocks starting in file 1 at block 10.

A wait event should identify the file and block (and row). If your wait event is for file #1 and block 12 you go off to USER_EXTENTS (or DBA_EXTENTS) and look for the extent in file# 1 where 12 is between the starting block location and the starting block location plus the number of blocks. So block 12 would between starting block 10 and end block 25 (start plus size).

Once you've identified the extent, you track it back to its parent segment (USER_SEGMENTS / DBA_SEGMENTS) which will give you the table/index name.


A theoretical SQL is as follows :

select username, sid, serial#, 
       row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#,
       ext.*
from v$session s
     join dba_extents ext on ext.file_id = row_wait_file#
     and row_wait_block# between ext.block_id and ext.block_id + ext.blocks - 1
where username = 'HR'
and status = 'ACTIVE'

For this one I purposefully blocked a session so that it was waiting on a row lock.

828 is a rather large file id. It isn't impossible, but it is unusual. Do a select from DBA_DATA_FILES and see if you have such a file. If not, and you've only got a few files, look at all the objects that match the "10711 between ext.block_id and ext.block_id + ext.blocks - 1" criteria without the file id. You should be able to find a likely candidate from there.

The exception is if the problem was on a temporary segment. Since these get disposed of at the end of the operation, there's no permanent object recorded. In that cases the 'name' of the table/index isn't applicable and you need to tackle any performance issue another way (eg look at the SQL and its explain plan and work out whether it is correct in using lots of temp space).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文