Table Sizing with LOB

If I define a LOB column in a table and if each record holds one large object document then how will we calculate the size of the table?
Do I need to take into account 4GB for each LOB in as many number of records?
Thanks in Advance.

Hi Sri
Have you looked at the following documents?
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4170157277722
http://jonathanlewis.wordpress.com/2007/05/11/lob-sizing/
Please read also
Doc ID: Note:268476.1
Subject: LOB Performance Guideline
May be this will help you out.

Similar Messages

R3load export of table REPOSRC with lob col - error ora-1555 and ora-22924

Hello,
i have tried to export data from our production system for system copy and then upgrade test. while i export the R3load job has reported error in table REPOSRC, which has lob column DATA. i have apsted below the conversation in which i have requested SAP to help and they said it comes under consulting support. this problem is in 2 rows of the table.
but i would like to know if i delete these 2 rows and then copy from our development system to production system at oracle level, will there be any problem with upgrade or operation of these prorgams and will it have any license complications if i do it.
Regards
Ramakrishna Reddy
__________________________ SAP SUPPORT COnveration_____________________________________________________
Hello,
we have are performing Data Export for System copy of our Production
system, during the export, R3load Job gave error as
R3LOAD Log----
Compiled Aug 16 2008 04:47:59
/sapmnt/DB1/exe/R3load -datacodepage 1100 -
e /dataexport/syscopy/SAPSSEXC.cmd -l /dataexport/syscopy/SAPSSEXC.log -stop_on_error
(DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): WE8DEC
(DB) INFO: Export without hintfile
(NT) Error: TPRI_PAR: normal NameTab from 20090828184449 younger than
alternate NameTab from 20030211191957!
(SYSLOG) INFO: k CQF :
TPRI_PAR&20030211191957&20090828184449& rscpgdio 47
(CNV) WARNING: conversion from 8600 to 1100 not possible
(GSI) INFO: dbname = "DB120050205010209
(GSI) INFO: vname = "ORACLE "
(GSI) INFO: hostname
= "dbttsap "
(GSI) INFO: sysname = "AIX"
(GSI) INFO: nodename = "dbttsap"
(GSI) INFO: release = "2"
(GSI) INFO: version = "5"
(GSI) INFO: machine = "00C8793E4C00"
(GSI) INFO: instno = "0020111547"
(DBC) Info: No commits during lob export
DbSl Trace: OCI-call 'OCILobRead' failed: rc = 1555
DbSl Trace: ORA-1555 occurred when reading from a LOB
(EXP) ERROR: DbSlLobGetPiece failed
rc = 99, table "REPOSRC"
(SQL error 1555)
error message returned by DbSl:
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
(DB) INFO: disconnected from DB
/sapmnt/DB1/exe/R3load: job finished with 1 error(s)
/sapmnt/DB1/exe/R3load: END OF LOG: 20100816104734
END of R3LOAD Log----
then as per the note 500340, i have chnaged the pctversion of table
REPOSRC of lob column DATA to 30, but i get the error still,
i have added more space to PSAPUNDO and PSAPTEMP also, still the same
error.
the i have run the export as
exp SAPDB1/sap file=REPOSRC.dmp log=REPOSRC.log tables=REPOSRC
exp log----
dbttsap:oradb1 5> exp SAPDB1/sap file=REPOSRC.dmp log=REPOSRC.log
tables=REPOSRC
Export: Release 9.2.0.8.0 - Production on Mon Aug 16 13:40:27 2010
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to: Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit
Production
With the Partitioning option
JServer Release 9.2.0.8.0 - Production
Export done in WE8DEC character set and UTF8 NCHAR character set
About to export specified tables via Conventional Path ...
. . exporting table REPOSRC
EXP-00056: ORACLE error 1555 encountered
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
Export terminated successfully with warnings.
SQL> select table_name, segment_name, cache, nvl(to_char
(pctversion),'NULL') pctversion, nvl(to_char(retention),'NULL')
retention from dba_lobs where
table_name = 'REPOSRC';
TABLE_NAME | SEGMENT_NAME |CACHE | PCTVERSION | RETENTION
REPOSRC SYS_LOB0000014507C00034$$ NO 30 21600
please help to solve this problem.
Regards
Ramakrishna Reddy
Dear customer,
Thank you very much for contacting us at SAP global support.
Regarding your issue would you please attach your ORACLE alert log and
trace file to this message?
Thanks and regards.
Hello,
Thanks for helping,
i attached the alert log file. i have gone through is, but i could
not find the corresponding Ora-01555 for table REPOSRC.
Regards
Ramakrishna Reddy
+66 85835-4272
Dear customer,
I have found some previous issues with the similar symptom as your
system. I think this symptom is described in note 983230.
As you can see this symptom is mainly caused by ORACLE bug 5212539 and
it should be fixed at 9.2.0.8 which is just your version. But although
5212539 is implemented, only the occurrence of new corruptions will be
avoided, the already existing ones will stay in the system regardless of the patch.
The reason why metalink 452341.1 was created is bug 5212539, since this
is the most common software caused lob corruption in recent times.
Basically any system that was running without a patch for bug 5212539 at some time in the past could be potentially affected by the problem.
In order to be sure about bug 5212539 can you please verify whether the
affected lob really is a NOCACHE lob? You can do this as described in
mentioned note #983230. If yes, then there are basically only two
options left:
-> You apply a backup to the system that does not contain these
corruptions.
-> In case a good backup is not available, it would be possible to
rebuild the table including the lob segment with possible data loss . Since this is beyond the scope of support, this would have to be
done via remote consulting.
Any further question, please contact us freely.
Thanks and regards.
Hello,
Thanks for the Help and support,
i have gone through the note 983230 and metalink 452341.1.
and i have ran the script and found that there are 2 rows corrupted in
the table REPOSRC. these rows belong to Standard SAP programs
MABADRFENTRIES & SAPFGARC.
and to reconfirm i have tried to display them in our development system
and production system. the development systems shows the src code in
Se38 but in production system it goes to short dump DBIF_REPO_SQL_ERROR.
so is it possible to delete these 2 rows and update ourselves from our
development system at oracle level. will it have any impact on SAP
operation or upgrade in future.
Regards
Ramakrishna Reddy

Hello, we have solved the problem.
To help someone with the same error, what we have done is:
1.- wait until all the processes has finished and the export is stopped.
2.- startup SAP
3.- SE14 and look up the tables. Crete the tables in the database.
4.- stop SAP
5.- Retry the export (if you did all the steps with sapinst running but the dialogue window in the screen) or begin the sapinst again with the option: "continue with the old options".
Regards to all.

Table Compression with LOBs

Hi,
I need some help with the Advanced Table Compression when creating a table especially when they contain a LOB.
Here are 3 examples:
Exp#1
CREATE TABLE emp (
      emp_id NUMBER,
      first_name VARCHAR2(128),
      last_name VARCHAR2(128)
) COMPRESS FOR OLTP;
This one is ok - all elements are compressed.
Exp#2
CREATE TABLE photos (
      photo_id NUMBER,
      photo BLOB)
      LOB(photo) STORE AS SECUREFILE (COMPRESS LOW);
This one I am confused - is it just the LOB(photo) that is compressed or the whole table. If it is just the LOB then what syntax do I need for the whole table?
I also assume that the LOB is being stored in the default tablespace associated with this table - correct me if I am wrong!
Exp#3
CREATE TABLE images (
      image_id NUMBER,
      image BLOB)
      LOB(image) STORE AS SECUREFILE (TABLESPACE lob_tbs COMPRESS);
This one I am confused - I think it is telling me that LOB(image) is being compresses and stored in tablespace lob_tbs and the other elements are being stored uncompressed in the default tablespace.
Again if it is just the LOB then what syntax do I need for the whole table?
Thanks & regards
-A

user12289108 wrote:
Exp#2
CREATE TABLE photos (
      photo_id NUMBER,
      photo BLOB)
      LOB(photo) STORE AS SECUREFILE (COMPRESS LOW);
This one I am confused - is it just the LOB(photo) that is compressed or the whole table. If it is just the LOB then what syntax do I need for the whole table?
I also assume that the LOB is being stored in the default tablespace associated with this table - correct me if I am wrong!
SecureFile LOB compression is independent of table compression and vice versa - Oracle Database 11g: The Top New Features for DBAs and Developers | SecureFiles

When comparing database tables with lob columns via "Database diff" in different environments indexes are shown as different

When using "Database diff" selecting other schemas only for compare own objects are shown too!Hi!
For tables with lob columns (clob, blob, etc.) indexes with system names are automatically created per lob column.
If I am on different database instances (eg. dev/test) these system names can differ and are shown as differences, but these is a false positive.
Unfortunately there is now way to influence the index names.
Any chance to fix this in sql developer?
Best regards
Torsten

Only the Sql Dev team can respond to that question.
Such indexes should ONLY be created by Oracle and should NOT be part of any DDL that you, the user, maintains outside the database since they will be created by Oracle when the table is created and will be named at that time.
It is up to the Sql Dev team to decide whether to deal with that issue and how to deal with it.

Oracle 11.2 - Perform parallel DML on a non partitioned table with LOB column

Hi,
Since I wanted to demonstrate new Oracle 12c enhancements on SecureFiles, I tried to use PDML statements on a non partitioned table with LOB column, in both Oracle 11g and Oracle 12c releases. The Oracle 11.2 SecureFiles and Large Objects Developer's Guide of January 2013 clearly says:
Parallel execution of the following DML operations on tables with LOB columns is supported. These operations run in parallel execution mode only when performed on a partitioned table. DML statements on non-partitioned tables with LOB columns continue to execute in serial execution mode.
INSERT AS SELECT
CREATE TABLE AS SELECT
DELETE
UPDATE
MERGE (conditional UPDATE and INSERT)
Multi-table INSERT
So I created and populated a simple table with a BLOB column:
SQL> CREATE TABLE T1 (A BLOB);
Table created.
Then, I tried to see the execution plan of a parallel DELETE:
SQL> EXPLAIN PLAN FOR
2 delete /*+parallel (t1,8) */ from t1;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3718066193
| Id | Operation             | Name     | Rows | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | DELETE STATEMENT      |          | 2048 |     2   (0)| 00:00:01 |        |      |            |
|   1 | DELETE               | T1       |       |            |          |        |      |            |
|   2 |   PX COORDINATOR      |          |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM)| :TQ10000 | 2048 |     2   (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) |
|   4 |     PX BLOCK ITERATOR |          | 2048 |     2   (0)| 00:00:01 | Q1,00 | PCWC |            |
|   5 |      TABLE ACCESS FULL| T1       | 2048 |     2   (0)| 00:00:01 | Q1,00 | PCWP |            |
PLAN_TABLE_OUTPUT
Note
   - dynamic sampling used for this statement (level=2)
And I finished by executing the statement.
SQL> commit;
Commit complete.
SQL> alter session enable parallel dml;
Session altered.
SQL> delete /*+parallel (t1,8) */ from t1;
2048 rows deleted.
As we can see, the statement has been run as parallel:
SQL> select * from v$pq_sesstat;
STATISTIC                      LAST_QUERY SESSION_TOTAL
Queries Parallelized                    1             1
DML Parallelized                        0             0
DDL Parallelized                        0             0
DFO Trees                               1             1
Server Threads                          5             0
Allocation Height                       5             0
Allocation Width                        1             0
Local Msgs Sent                        55            55
Distr Msgs Sent                         0             0
Local Msgs Recv'd                      55            55
Distr Msgs Recv'd                       0             0
11 rows selected.
Is it normal ? It is not supposed to be supported on Oracle 11g with non-partitioned table containing LOB column....
Thank you for your help.
Michael

Yes I did it. I tried with force parallel dml, and that is the results on my 12c DB, with the non partitionned and SecureFiles LOB column.
SQL> explain plan for delete from t1;
Explained.
| Id | Operation             | Name     | Rows | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | DELETE STATEMENT      |          |     4 |     2   (0)| 00:00:01 |        |      |            |
|   1 | DELETE               | T1       |       |            |          |        |      |            |
|   2 |   PX COORDINATOR      |          |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM)| :TQ10000 |     4 |     2   (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) |
|   4 |     PX BLOCK ITERATOR |          |     4 |     2   (0)| 00:00:01 | Q1,00 | PCWC |            |
|   5 |      TABLE ACCESS FULL| T1       |     4 |     2   (0)| 00:00:01 | Q1,00 | PCWP |            |
The DELETE is not performed in Parallel.
I tried with another statement :
SQL> explain plan for
2        insert into t1 select * from t1;
Here are the results:
11g
| Id | Operation                | Name     | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | INSERT STATEMENT         |          |     4 | 8008 |     2   (0)| 00:00:01 |        |      |            |
|   1 | LOAD TABLE CONVENTIONAL | T1       |       |       |            |          |        |      |            |
|   2 |   PX COORDINATOR         |          |       |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM)   | :TQ10000 |     4 | 8008 |     2   (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) |
|   4 |     PX BLOCK ITERATOR    |          |     4 | 8008 |     2   (0)| 00:00:01 | Q1,00 | PCWC |            |
|   5 |      TABLE ACCESS FULL   | T1       |     4 | 8008 |     2   (0)| 00:00:01 | Q1,00 | PCWP |            |
12c
| Id | Operation                          | Name     | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | INSERT STATEMENT                   |          |     4 | 8008 |     2   (0)| 00:00:01 |        |      |            |
|   1 | PX COORDINATOR                    |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)              | :TQ10000 |     4 | 8008 |     2   (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) |
|   3 |    LOAD AS SELECT                  | T1       |       |       |            |          | Q1,00 | PCWP |            |
|   4 |     OPTIMIZER STATISTICS GATHERING |          |     4 | 8008 |     2   (0)| 00:00:01 | Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR             |          |     4 | 8008 |     2   (0)| 00:00:01 | Q1,00 | PCWC |            |
It seems that the DELETE statement has problems but not the INSERT AS SELECT !

ASSM and table with LOB column

I have a tablespace created with ASSM option. I've heard about that tables with LOB columns can't take the advantage of ASSM.
I made a test : create a table T with BLOB column in a ASSM tablespace. I succeeded!
Now I have some questions:
1. Since the segments of table T can't use ASSM to manage its blocks, what's the actrual approach? The traditional freelists??
2. Will there be some bad impacts on the usage of the tablespace if table T becomes larger and larger and is used frequently?
Thanks in advance.

Can you explain what you mean by #1 because I believe it is incorrect and it does not make sense in my personal opinion. You can create a table in an ASSM tablespace that has a LOB column from 9iR2 on I believe (could be wrong). LOBs don't follow the traditional PCTFREE/PCTUSED scenario. They allocate data in what are called "chunks" that you can define at the time you create the table. In fact I think the new SECUREFILE LOBs actually require ASSM tablespaces.
HTH!

Export table with LOB column

Hi!
I have to export table with lob column (3 GB is the size of lob segment) and then drop that lob column from table. Table has about 350k rows.
(I was thinking) - I have to:
1. create new tablespace
2. create copy of my table with CTAS in new tablespace
3. alter new table to be NOLOGGING
4. insert all rows from original table with APPEND hint
5. export copy of table using transport tablespace feature
6. drop newly created tablespace
7. drop lob column and rebuild original table
DB is Oracle 9.2.0.6.0.
UNDO tablespace limited on 2GB with retention 10800 secs.
When I tried to insert rows to new table with /*+append*/ hint operation was very very slow so I canceled it.
How much time should I expect for this operation to complete?
Is my UNDO sufficient enough to avoid snapshot too old?
What do you think?
Thanks for your answers!
Regards,
Marko Sutic

I've seen that document before I posted this question.
Still I don't know what should I do. Look at this document - Doc ID: 281461.1
From that document:
FIX
Although the performance of the export cannot be improved directly, possible
alternative solutions are:
+1. If not required, do not use LOB columns.+
or:
+2. Use Transport Tablespace export instead of full/user/table level export.+
or:
+3. Upgrade to Oracle10g and use Export DataPump and Import DataPump.+
I just have to speed up CTAS little more somehow (maybe using parallel processing).
Anyway thanks for suggestion.
Regards,
Marko

Add columns to a table with lob column

Hi,
Just a quick question: is there a performance penalty after adding columns to a table with a lob fied? the lob field is now the last column in the table and via via I was told that adding columns will impact badly the IO performance on the table if the lob field isn't anymore the last column. The table is on a Oracle 10.2.0.3 version.
thanks. regards
Ivan

Havent heard of performance degradation specifically due to a LOB column not being the last column in a table (although there are several issues with just having a LOB column in a table).
You may want to build a test database to test it out. It should be easy to run tests comparing one with the additional column and one the original to prove or refute it. The results would be interesting to learn - please post them up if you intend to test it out.

Table with LOB column

Hi,
I have a proble. How to move a table with LOB colum? How to create a table with LOB column by specifying another tablespace for LOB column?
Please help me.
Regards,
Mathew

What is it that you are not able to find?
The link that I provided was answer to your second question.

Protected memory exception during bulkcopy of table with LOB columns

Hi,
I'm using ADO BulkCopy to transfer data from a SqlServer database to Oracle. In some cases, and it seems to only happen on some tables with LOB columns, I get the following exception:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at Oracle.DataAccess.Client.OpsBC.Load(IntPtr opsConCtx, OPOBulkCopyValCtx* pOPOBulkCopyValCtx, IntPtr pOpsErrCtx, Int32& pBadRowNum, Int32& pBadColNum, Int32 IsOraDataReader, IntPtr pOpsDacCtx, OpoMetValCtx* pOpoMetValCtx, OpoDacValCtx* pOpoDacValCtx)
at Oracle.DataAccess.Client.OracleBulkCopy.PerformBulkCopy()
at Oracle.DataAccess.Client.OracleBulkCopy.WriteDataSourceToServer()
at Oracle.DataAccess.Client.OracleBulkCopy.WriteToServer(IDataReader reader)
I'm not sure exactly what conditions trigger this exception; perhaps only when the LOB data is large enough?
I'm using Oracle 11gR2.
Has anyone seen this or have an idea how to solve it?
If I catch the exception and attempt row-by-row copying, I then get "ILLEGAL COMMIT" exceptions.
Thanks,
Ben

From the doc:
Data Types Supported by Bulk Copy
The data types supported by Bulk Copy are:
ORA_SB4
ORA_VARNUM
ORA_FLOAT
ORA_CHARN
ORA_RAW
ORA_BFLOAT
ORA_BDOUBLE
ORA_IBDOUBLE
ORA_IBFLOAT
ORA_DATE
ORA_TIMESTAMP
ORA_TIMESTAMP_TZ
ORA_TIMESTAMP_LTZ
ORA_INTERVAL_DS
ORA_INTERVAL_YM
I can't find any documentation on these datatypes (I'm guessing these are external datatype constants used by OCI??). This list suggests ADO.NET bulk copy of LOBs isn't supported at all (although it works fine most of the time), unless I'm misreading it.
The remaining paragraphs don't appear to apply to me.
Thanks,
Ben

A Query with LOB's requires OCI8 mode, but OCI7 mode is used

Hello all,
I am using Oracle 10g. We have two tables and in that, in one table i have a Long Raw Column and in the other table i have a BLOB field. When i use the select query to fetch the details from the table with Long Raw field it is working fine and at the same time if i use the select query on the table with the BLOB field it is giving me an error
'A query with LOB's requires OCI8 mode, but OCI7 mode is used.'
Please help.
Thanks.
Vinodh. S

Hi Oleg,
I think your client machine is not setup to connect to the Database. Run the Oracle Net8 Assistant or the Net8 Easy Config to connect to the Database.
This should work.
Samuel.
PS: I need someone to answer my question, please

Unable to Move Parts of a Table that are LOB's

Hello -
I'm running Oracle 8.1.7.4. I moved a table from one tablespace to another by issuing the following command:
alter tableA move tablespace SomeTS;
I noticed that the table now resides in SomeTS, but the LOB data types still reside in the OldTS. Is there a relatively easy way to get the LOB segments in new tablespace?
Thx.

The statement "alter tableA move tablespace SomeTS;" will rebuild the table tableA segment, but will not rebuild the lob segments of your lob column (e.g lobA).
You need the following syntax to move the tables and its LOB column.
ALTER TABLE tableA MOVE
TABLESPACE SomeTS
LOB (lobA) STORE AS (TABLESPACE SomeTS);
Since you have already moved the table, you can move only the LOB column with this syntax
ALTER TABLE tableA MOVE LOB(llobA)
STORE AS (TABLESPACE SomeTS);

Import problem with LOBs

Hi,
Oracle 9.2.0.4
Solaris 9
I have just tried to import a schema with LOBs (mainly CLOBs, I think). The export was from a schema residing in a tablespace 'LUM' and going to an instance with a tablespace 'LUMTEST'.
The documentation and experience says that importing into a different ts from the exported ts (exported ts does not exist on target) should place the objects into the default ts of the 'touser' parameter. This happened for all tables that did not include a LOB column. However, the creation of the tables with a LOB column failed.
Is this a known problem or a bug, and is there a fix for it? (or is it a feature?!)
Thanks,
Jonathan Paul
Royal Holloway, University of London
OCP DBA

Raj is correct for tables not containing LOBs. Tables containing LOBs have two tablespace specifications in the SQL that creates them. This is because the LOB column can be in a different tablespace. I questioned this some time back when I first discovered it, and was told by an Oracle employee on the Metalink forum that this was the "expected behavior".
So it is NOT a bug according to them, but rather as you guessed a "feature". To get around it create the table in advance in the tablespaces you want, then do your import with parameter ignore=y to ignore the error that import will generate because the table already exists.

Initial load with LOBs

Hi, i'm trying to do an inital load and I keep getting errors like these:
ERROR OGG-01192 Oracle GoldenGate Capture for Oracle, ext1.prm: Trying to use RMTTASK on data types which may be written as LOB chunks (Table: 'TESTDB.BLOBTABLE').
ERROR OGG-01668 Oracle GoldenGate Capture for Oracle, ext1.prm: PROCESS ABENDING.
The table looks like this:
COLUMN_NAME|DATA_TYPE|NULLABLE|DATA_DEFAULT|COLUMN_ID|COMMENTS
UUID     VARCHAR2(32 BYTE)     No          1
DESCRIPTION     VARCHAR2(2000 BYTE)     Yes          2
CONTENT     BLOB     Yes          3
I've checked and the source database does contain data in the blobtable and both databases have the same tables, so now I have no idea what can be wrong? =/

For initial loads with LOBs, use a RMTFILE and a normal replicat. There are a number of things that are not supported with "RmtTask". A "rmtfile" is basically the same format as a 'rmttrail' file, but is specifically for initial loads or other "captured" data that is not a continuous stream. And make sure you do have a newer build of GG (either v11 or a latest 10.4 from the support site).
The 'extract' would look something like this:
ggsci> add extract e1aa, sourceIsTable
ggsci> edit param e1aa
extract e1aa
userid ggs, password ggs
-- either local or remote
-- extFile dirdat/aa, maxFiles 999999, megabytes 100
rmtFile dirdat/aa, maxFiles 999999, megabytes 100
Table myschema1.*;
Table myschema2.*;
Then on the target, use a normal 'replicat' to read the "files".
Note that if the source and target are both oracle, this is not the most efficient way to instantiate the target. Using export/import or backup/restore (or any other mechanism) would usually be preferable.

Fastest and easiest way to drop a tablespace with LOB Segments

When I try to drop a tablespace I get a message that I can't cause it still contains LOB Segments. I searched to see what objects like tables or indexes are in that tablespace and there are none.
Any one run into this? Any way to get around this issue?

Sorry,
Version = 10.2.0.4
OS = Win2003 32bit
Command used = DROP TABLESPACE IWORKS_LARGE_TABLES INCLUDING CONTENTS AND DATAFILES;
Error Message = ORA-22868: table with LOBs contains segments in different tablespaces
Objects currently in this tablespace:
SQL> select s.segment_name, s.segment_type
2    from dba_segments s
3   where tablespace_name = 'IWORKS_LARGE_TABLES'
4 ;
SEGMENT_NAME                                                                     SEGMENT_TYPE
SYS_IL0000060885C00008$$                                                         LOBINDEX
SYS_LOB0000060885C00008$$                                                        LOBSEGMENT
SYS_IL0000060918C00048$$                                                         LOBINDEX
SYS_LOB0000060918C00048$$                                                        LOBSEGMENTI basically want to drop the whole tablespace but these objects are not allowing me to.

Table Sizing with LOB

Similar Messages

Maybe you are looking for