How To Find Lob Segment Table In Oracle

Locating the LOB segment table within an Oracle database involves understanding the structure of LOB data storage and utilizing specific data dictionary views. A LOB (Large Object) segment stores unstructured data such as images, audio, or documents. This article provides a structured approach to identifying the table associated with a specific LOB segment.
Prerequisites
Before proceeding, ensure you have:
- Access to the Oracle database with appropriate privileges (typically
SELECTaccess on data dictionary views). - The name or object ID (
data_object_id) of the LOB segment you wish to investigate.
Step 1: Identifying the LOB Segment
First, identify the specific LOB segment of interest. This can be achieved through various monitoring tools or SQL queries that provide information about database segments. Common sources of this information include performance monitoring dashboards, AWR reports, or customized SQL scripts.
Must Read
Once you have identified the LOB segment, note its segment name and, more importantly, its data_object_id. The data_object_id is a unique identifier for the segment within the database.
Step 2: Querying the DBA_LOBS View
The DBA_LOBS view contains metadata about LOB columns within the database. This view provides information such as the table name, column name, and LOB segment name associated with each LOB column.
To find the table associated with a specific LOB segment, query the DBA_LOBS view using the SEGMENT_NAME or DATA_OBJECT_ID. Use the following SQL query:
SELECT OWNER, TABLE_NAME, COLUMN_NAME FROM DBA_LOBS WHERE SEGMENT_NAME = 'YOUR_LOB_SEGMENT_NAME';
Replace YOUR_LOB_SEGMENT_NAME with the actual name of the LOB segment you identified in Step 1. Alternatively, if you have the DATA_OBJECT_ID, use the following query:

SELECT OWNER, TABLE_NAME, COLUMN_NAME FROM DBA_LOBS WHERE DATA_OBJECT_ID = YOUR_LOB_DATA_OBJECT_ID;
Replace YOUR_LOB_DATA_OBJECT_ID with the numerical DATA_OBJECT_ID of the LOB segment.
The query results will return the OWNER (schema), TABLE_NAME, and COLUMN_NAME associated with the specified LOB segment. This identifies the table containing the LOB column that utilizes the segment.
Step 3: Considering Partitioned Tables
If the table identified in Step 2 is partitioned, the LOB data might be stored in separate LOB segments for each partition. In this case, you need to consider the DBA_LOB_PARTITIONS view.
The DBA_LOB_PARTITIONS view provides information about LOB partitions, including the partition name, segment name, and other partition-specific details. Use this view in conjunction with the DBA_LOBS view to pinpoint the exact table and partition associated with the LOB segment.

First, use the query from Step 2 to identify the base table name. Then, use the following query to find the partition details:
SELECT OWNER, TABLE_NAME, PARTITION_NAME FROM DBA_LOB_PARTITIONS WHERE SEGMENT_NAME = 'YOUR_LOB_SEGMENT_NAME';
Replace YOUR_LOB_SEGMENT_NAME with the LOB segment name. The results will show the OWNER, TABLE_NAME, and PARTITION_NAME associated with the LOB segment.
Alternatively, you can join DBA_LOBS and DBA_LOB_PARTITIONS views using DATA_OBJECT_ID:
SELECT dl.OWNER, dl.TABLE_NAME, dlp.PARTITION_NAME, dl.COLUMN_NAME FROM DBA_LOBS dl JOIN DBA_LOB_PARTITIONS dlp ON dl.DATA_OBJECT_ID = dlp.DATA_OBJECT_ID WHERE dlp.SEGMENT_NAME = 'YOUR_LOB_SEGMENT_NAME';
This query provides a combined view of the table, partition, and column associated with the specified LOB segment.

Step 4: Dealing with Subpartitions
Similar to partitioned tables, LOB data in subpartitioned tables might be stored in separate LOB segments for each subpartition. The DBA_LOB_SUBPARTITIONS view provides information about LOB subpartitions. Use this view to pinpoint the table and subpartition associated with the LOB segment.
First, identify the base table name using the query from Step 2. Then, use the following query:
SELECT OWNER, TABLE_NAME, SUBPARTITION_NAME FROM DBA_LOB_SUBPARTITIONS WHERE SEGMENT_NAME = 'YOUR_LOB_SEGMENT_NAME';
Replace YOUR_LOB_SEGMENT_NAME with the LOB segment name. The results will show the OWNER, TABLE_NAME, and SUBPARTITION_NAME associated with the LOB segment.
Alternatively, you can join DBA_LOBS and DBA_LOB_SUBPARTITIONS views using DATA_OBJECT_ID:

SELECT dl.OWNER, dl.TABLE_NAME, dls.SUBPARTITION_NAME, dl.COLUMN_NAME FROM DBA_LOBS dl JOIN DBA_LOB_SUBPARTITIONS dls ON dl.DATA_OBJECT_ID = dls.DATA_OBJECT_ID WHERE dls.SEGMENT_NAME = 'YOUR_LOB_SEGMENT_NAME';
This query provides a combined view of the table, subpartition, and column associated with the specified LOB segment.
Step 5: Handling SecureFiles LOBs
Since Oracle 11g, SecureFiles LOBs have been introduced. SecureFiles LOBs provide better performance and advanced features compared to BasicFiles LOBs. Determining the associated table follows a similar process, leveraging data dictionary views.
The queries outlined in steps 2, 3 and 4 will also work for SecureFiles LOBs as they utilize the same underlying data dictionary views, such as DBA_LOBS, DBA_LOB_PARTITIONS and DBA_LOB_SUBPARTITIONS.
Practical Considerations and Insights
- Permissions: Ensure you have the necessary permissions to query the data dictionary views. If you lack sufficient privileges, consult your database administrator.
- Case Sensitivity: LOB segment names are case-sensitive. Verify the correct case when using segment names in your queries.
- Dynamic Environments: In dynamic environments with frequent table alterations or partition management, consider refreshing your metadata or using dynamic SQL to ensure accurate results.
- Monitoring: Proactively monitor LOB segment growth and performance. Identifying large or problematic LOB segments early can prevent performance bottlenecks. Tools like Oracle Enterprise Manager or custom monitoring scripts can be invaluable.
- Troubleshooting: If you encounter errors or unexpected results, verify the LOB segment name or
DATA_OBJECT_IDis correct. Also, ensure the LOB segment exists and is accessible. - Performance: When querying data dictionary views, consider adding appropriate
WHEREclauses to limit the data retrieved. This can improve query performance, especially in large databases.
