Index going to SYSTEM tablespace?

I've set up a basic_storage preference where INDX is my tablespace name as follows:
BEGIN
ctx_ddl.create_preference('MYSTORE', 'BASIC_STORAGE');
ctx_ddl.set_attribute('MYSTORE', 'I_TABLE_CLAUSE',
'tablespace INDX storage (initial 32K)');
ctx_ddl.set_attribute('MYSTORE', 'K_TABLE_CLAUSE',
'tablespace INDX storage (initial 32K)');
ctx_ddl.set_attribute('MYSTORE', 'R_TABLE_CLAUSE',
'tablespace INDX storage (initial 32K)');
ctx_ddl.set_attribute('MYSTORE', 'N_TABLE_CLAUSE',
'tablespace INDX storage (initial 32K)');
ctx_ddl.set_attribute('MYSTORE', 'I_INDEX_CLAUSE',
'tablespace INDX storage (initial 32K)');
END;
Then I create my context index like this:
CREATE INDEX I_FORM_TITLE_WORD ON FORMS(FORM_TITLE)
indextype is ctxsys.context
PARAMETERS('storage MYSTORE populate');
Everything seems to get created properly with no errors but I have questions regarding the storage parameters:
1. I get the following when I select index_name, tablespace_name from user_indexes:
DR$I_FORM_TITLE_WORD$X INDX
I_FORM_TITLE_WORD SYSTEM
Why is I_FORM_TITLE_WORD in the SYSTEM tablespace and is it possible to move it to INDX?
2. I get the following when I select table_name, tablespace_name from user_tables:
DR$I_FORM_TITLE_WORD$I INDX
DR$I_FORM_TITLE_WORD$K
DR$I_FORM_TITLE_WORD$N
DR$I_FORM_TITLE_WORD$R INDX
Why is there nothing listed for the KEYMAP and NEGATIVE LIST tables?
Any insight into these questions/concerns would be greatly appreciated.
Thanks,
Diane
null

Thanks for the info regarding the K and N tables but I'm still confused about how the I_FORM_TITLE_WORD got created in the SYSTEM tablespace.
I agree that I don't want I_FORM_TITLE_WORD in the SYSTEM tablespace if possible. That's the main reason for my posting.
First, I thought because I specified:
PARAMETERS('storage MYSTORE populate')
in the index creation that it would automatically put all pieces (index and table parts) into my INDX tablespace.
Second, even if the above failed to be true, I created the index as a user that has it's own separate tablespace set as a default. So at least why wasn't the I_FORM_TITLE_WORD created in that user's tablespace?
Diane
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Adeeva ([email protected]):
I'd recommend creating a separate tablespace
called CTX_INDX or similar. Using SYSTEM as
the default can be dangerous if you don't
know what's going to be loaded into it. If
you didn't specify a storage clause, this
is where they go. Plus, some of the little
admin tables that get created by the system
don't give you the option.
The K and N tables are created as Index Organised Tables (IOT) and still create
as per the STORAGE definitions, but you
just can't see this in the view.<HR></BLOCKQUOTE>
null

Similar Messages

  • Does rebuild of indexes uses temp tablespace or system tablespace?

    Does rebuild of indexes uses temp tablespace or system tablespace?
    If so why?

    If you combine the answers from Aman and Burleson, they cover most of the picture.
    When rebuilding an index, you may end up sorting a large amount of information. The sort may spill into the temporary tablespace - if you haven't configured your database and users properly, it is possible that the SYSTEM tablespace may be used for the temporary tablespace.
    As the new copy of the index is built, it has to be built in the right place (tablespace), and the space used to build it will be marked as a temporary segment as the build takes place. When the build is complete, this temporary segment will take on the name of the origrinal index, and the original index will be re-badged as a temporary segment and dropped. (Again, you might see temporary segments in the SYSTEM tablespace if the index was originally in, or was rebuilt into, the SYSTEM tablespace).
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk

  • Why domain(context) indexes taking system tablespace

    when i createing domain(context) index it is taking system tablespace . i tryed for createing another tablespace it is giving error. if any one knows please help me.
    null

    You're looking at USER_INDEXES, and those data dictionary views? Yes, for some reason it always puts the
    tablespace as SYSTEM. But don't worry, there isn't actual storage associated (except maybe the few bytes
    to store the index name, id, etc in the data dictionary itself). The real storage is the internal DR$ tables, which
    you seem to have already redirected as you please.

  • No privileges on system tablespace?

    I am a new dba & have succesfully created tables and added constraints.
    Today I tried to add a constraint to an existing table, and received the message
    ORA-01950: no privileges on tablespace 'SYSTEM'
    I tried to add the constraint as the owner of the table, as a user with granted privs on the table, and finally as SYS, and get the same error.
    The system tablespace is only about 60% full, and I have not changed any user privs since I last sucessfully added constraints.
    If someone would give me a clue as to what's going on, I would really appreciate it.
    Thanks, Helen

    I granted unlimited tablespace to the user that owns the table, and the constraint was added successfully.
    I don't know if a user should have unlimited tablespace on SYSTEM...any advice on what a good limit would be? My system tablespace is 325 M and about 60% full. Would it make sense to grant sys unlimited tablespace on SYSTEM?
    Thanks very much for your help. You gave me the incentive to keep trying things until something worked.

  • Migrating SYSTEM tablespace from DMTS to LMTS in Oracle 9.2.0.7

    Migrating SYSTEM tablespace from DMTS to LMTS in Oracle 9.2.0.7 using
    brspace -f dbcreate
    SAP version: 4.6C
    Oracle: 9.2.0.7
    OS: AIX 5.3
    BRTools: 6.40(42)    /**  6.40(10) or (12) will be sufficient according to SAP ***/
    IMPORTANT ***************************************
    MUST DO:
    1. Create a Full Backup of your system
    2. Test your Restore and recovery of your backup.
    3. Have a copy of all your tablespaces names on hand
    4. Know your SYS and SYSTEM passwords
    5. Run CheckDB in DB13 to ensure it is completed successfully with no warnings. This reduce the chance of hitting errors in the process
    6. Ensure your UNDO tablespace is big enough
    7. OSS 400241 Problems with ops$ or sapr3 connect to Oracle
    NOTE: OSS 706625(Read this note)
    The migration from a dictionary-managed SYSTEM tablespace to a locally-managed tablespace using the PL/SQL procedure DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL is not supported in the SAP environment.
    In UNIX, logon as ora<sid>
    run command: brspace -f dbcreate
    This command will triggers a Menu. The are seven(7) steps to complete the whole process. Do them in sequence, from step 1 to step 7 faithfully. In Step 1, ensure that your settings of PSAPTEMP, PSAPUNDO etc details such as filenames are correct. The rest I leave it as default and they are fine. Do not change redo log group from 8 to 4 even if you only have 4 redo groups. If not, you might need to restore the system! If the seven steps are complete without errors(warnings is acceptable), congrats. Perform a backup again.
    Problems I encountered that caused me to restore system:
    1./ Problem: I changed the redo group from 8 to 4 and in the later stage after the tablespaces and files are dropped, the system prompted me that 4 is not acceptable! I can't go back then so a restore is performed.
    Solution: Leave the default value 8 as it is
    2./ I was using wireless network and the network breaks thus process breaks.
    Solution: This process in user-interactive and requires you to input confirmation along the way so do it using LAN.
    3./ In the process of dropping  tablespace PSAP<SID>, I encountered:
    BR0301E SQL error -604 at location BrTspDrop-2
    ORA-00601: error occurred at recursive SQL level 1
    ORA-01555: snapshot too old: rollback segment number 22 with name '_SYSSMU22$" too small
    Solution: I have not fixed this yet but I think it is because my PSAPUNDO is too small(800M) so I will increase it to a bigger value e.g. 5GB
    4. Problem: Unable to start sap after successfully migrated. OPS$user problem
    Solution: logon as <sid>adm, run R3trans -x in a directory that <sid>adm has read/write permission. R3trans -x will creates a file call trans.log. Read the details and refer to OSS 400241
    Result: I have successfully performed this on one(1) system and doing this on the another one currently but encounter Problem 3. Will update this further if there are more findings.
    REFERENCE:
    OSS 748434 New BRSPACE function "dbcreate" - recreate database
    OSS 646681 Reorganizing tables with BRSPACE
    OSS 541538 FAX: Reorganizations
    Message was edited by:
            Annie Chan
    Message was edited by:
            Annie Chan
    Message was edited by:
            Annie Chan

    The current one I am implementing is a development system. The database is less than 100GB. 800MB of PSAPUNDO is sufficient for our development usage.
    Follow up on Problem 3:
    I created another undo tablespace PSAPUNDO2(undodata.dbf) with size of 5GB. I switched undo tablespace to PSAPUNDO2 and placed PSAPUNDO(undo.data1) offline. With PSAPUNDO2 online and PSAPUNDO offline, I started brspace -f dbcreate and encountered the error below at Step 2 Export User tablespace:
    BR0301E SQL error -376 at location BrStattabCreate-3
    ORA-00376: file 17 cannot be read at this time
    ORA-01110: data file 17: '/oracle/DVT/sapdata1/undo_1/undo.data1'
    ORA-06512: at 'SYS.DBMS_STATS", line 5317
    ORA-06512: at line 1
    I aborted the process and verified that SAP is able to run with this settings. I started CheckDB in DB13 and it shows me these messages:
    BR0301W SQL error -376 at location brc_dblog_open-5
    ORA-00376: file 17 cannot be read at this time
    ORA-01110: data file 17: '/oracle/DEV/sapdata1/undo_1/undo.data1'
    BR0324W Insertion of database log header failed
    I don't understand then. I have already switched the undo tablespace from PSAPUNDO to PSAPUNDO2. Why the message above still appears? Once I put PSAPUNDO online, CheckDB completes successfully without warning.
    I did show parameter undo_tablespace and the result is PSAPUNDO2(5GB).
    So exactly, what's going on? Can anyone advise?
    ===============================================
    I have managed to clear the message in DB13 after dropping PSAPUNDO tablespace including contents and datafiles. This is mentioned is OSS note 600141 pg 8 as below:
    Note: You cannot just set the old rollback-tablespace PSAPROLL to offline instead of deleting it properly. This results in ORA-00376 in connection with ORA-01110 error messages. PSAPROLL must remain ONLINE until it is deleted. (Oracle bug 3635653)
    Message was edited by:
            Annie Chan

  • Why the system tablespace increase a lot?

    I have noticed that the system tablespace of my prod Oracle 10g R2 on AIX 5.3L reaches over the 85% warning level now, and the size has increased from ~68% to 88% of 1.6G total assigned capacity during the last 7 months. How do i find out what reason causes the increase? can I remove some "fat" out of them? or just keep increasing the size? My fresh backup AIX 5.3L system with the same 10g R2 only takes 38% of 1.6 G.

    SEGMENT_NAME SEGMENT_TYPE MBYTES
    SYS_LOB0000125172C00039$$ LOBSEGMENT 152
    C_OBJ#_INTCOL# CLUSTER 136
    I_CON1 INDEX 104
    C_OBJ# CLUSTER 96
    C_COBJ# CLUSTER 88
    HIST_HEAD$ TABLE 57
    CON$ TABLE 41
    I_COL1 INDEX 41
    C_FILE#_BLOCK# CLUSTER 38
    I_HH_OBJ#_COL# INDEX 34
    I_HH_OBJ#_INTCOL# INDEX 34
    SOURCE$ TABLE 32
    I_CON2 INDEX 27
    IDL_UB1$ TABLE 26
    I_CDEF4 INDEX 26
    I_H_OBJ#_COL# INDEX 25
    I_COL2 INDEX 20
    OBJ$ TABLE 19
    I_COL3 INDEX 19
    I_CCOL1 INDEX 19
    I saw some LOB segments in SYS; however my fresh new 10g R2 (v SE) on other AIX machine does not list those. Where are they from?
    I checked the user_lobs, Here are the tables which has LOB seg stored the system tablespace
    AW_OBJ$
    VIEWCON$
    SNAP$
    SNAP$
    TABPART$
    INDPART$
    TABSUBPART$
    INDSUBPART$
    TABCOMPART$
    INDCOMPART$
    DEFSUBPART$
    KOTTD$
    KOTTB$
    KOTAD$
    KOTMD$
    KOTTBX$
    KOTADX$
    SUM$
    SUM$
    SQL$TEXT
    METASTYLESHEET
    EXTERNAL_TAB$
    EXTERNAL_TAB$
    JIREFRESHSQL$
    AUD$
    AUD$
    FGA_LOG$
    FGA_LOG$
    PS$
    STREAMS$_DEF_PROC
    STREAMS$_DEF_PROC
    STREAMS$_DEF_PROC
    REDEF_DEP_ERROR$
    NCOMP_DLL$
    EXPIMP_TTS_CT$
    ATTRIBUTE_TRANSFORMATIONS$
    RULE$
    RULE$
    REG$
    AQ_EVENT_TABLE
    AQ_SRVNTFN_TABLE
    AQ_SRVNTFN_TABLE
    SCHEDULER$_JOBQTAB
    SCHEDULER$_JOBQTAB
    SCHEDULER$_JOB_ARGUMENT
    SCHEDULER$_PROGRAM_ARGUMENT
    SCHEDULER$_EVENT_QTAB
    KUPC$DATAPUMP_QUETAB
    KUPC$DATAPUMP_QUETAB
    KUPC$DATAPUMP_QUETAB
    KUPC$DATAPUMP_QUETAB
    KUPC$DATAPUMP_QUETAB
    KUPC$DATAPUMP_QUETAB
    KUPC$DATAPUMP_QUETAB
    STREAMS$_INTERNAL_TRANSFORM
    AQ$_MEM_MC
    AQ$_MEM_MC
    AQ$_KUPC$DATAPUMP_QUETAB_P
    AQ$_KUPC$DATAPUMP_QUETAB_P
    AQ$_KUPC$DATAPUMP_QUETAB_P
    AQ$_KUPC$DATAPUMP_QUETAB_P
    AQ$_KUPC$DATAPUMP_QUETAB_P
    AQ$_KUPC$DATAPUMP_QUETAB_P
    AQ$_KUPC$DATAPUMP_QUETAB_P
    AQ$_KUPC$DATAPUMP_QUETAB_D
    SYS_EXPORT_FULL_01
    SYS_EXPORT_FULL_02
    Does not look like any non-system user here?
    Message was edited by:
    user508054

  • InterMedia leaves garbage in the system tablespace

    During the creation of a context(interMedia) index, I shutdown
    the Oracle server with abort. I started the server up and
    proceeded to delete the bad index. When I tried to create a new
    index with the same name an error occured. I looked in some
    tables in the system tablespace under the ctxsys user, and found
    references to my corrupted index. Is there a way to clear out
    this bad data w/o having to re-install Oracle?

    You don't say what the error is so I can't be sure, but I
    suspect that deleting the entry in dr$index (owned by ctxsys)
    for your 'bad' index will allow you to recreate it.

  • System tablespace

    I have created a table in the system tablespace. I am able to rename the column in the table, add a new column to the table, modify the column in the table. But when I tried to drop the column in the table, the following error is raised.
    ORA-12988: cannot drop column from table owned by SYS
    The user is connected as a sysdba. What is the logic that goes behind this error, as we are able to create a new table in system tablespace, rename the column, modify the column in the table and add new columns to the table. But we couldn't drop a column in the same table.

    I have created a table in the system tablespace. Wrong idea
    I am able to rename the column in the table, add a new
    column to the table, modify the column in the table.
    But when I tried to drop the column in the table, the
    following error is raised.
    ORA-12988: cannot drop column from table owned by
    SYS
    Connect as SYS and drop it.
    The user is connected as a sysdba. What is the logic
    that goes behind this error, as we are able to create
    a new table in system tablespace, rename the column,
    modify the column in the table and add new columns to
    the table. But we couldn't drop a column in the same
    table.Creating a new table in system tablespace is one thing. Creating a table connected as SYSDBA is a different thing.
    So you have two wrongs to correct.
    1. Do not create new tables in system tablespace. Create a new tablespace for users (if you do not have one).
    2. Do not connect as sysdba to create new tables. Connect as that user without sysdba.

  • Transport table from system tablespace to another tablespace

    hi there,
    how can we transport a table from system tablespace to another tablespace(example users tablespace)?

    Assuming you are not trying to move any data dictionary tables.
    Use alter table to move it,
    ALTER TABLE my_table MOVE TABLESPACE USERS;
    Rebuild index after move.
    This will work on Oracle 9i and above.

  • System Tablespace Resize --Crusial thing happened

    Hi
    When I disconnected permission on a temporary tablespace
    to a user, I forget his permission on the system tablespace.
    One of his query consumed more than 1 gb size in system
    tablespace.
    Now I am getting ORA-03297 When tried to resize.
    Suggestions are highly appriciated.
    Thanks
    giri

    Narayanan V giri , this script is going to help you
    for checking locks in the database and its sessions.
    Try to kill them before resize.
    col object_name format a20
    col username format a10
    col oracle_username format a10
    col process format a15
    col owner format a10
    prompt ****************************************************************
    prompt *** Object Lock Contention ***
    prompt ****************************************************************
    set pages 0
    set linesize 150
    select 'Date : '||to_char(sysdate,'DD/MM/YYYY')||' Time : '||to_char(sysdate,'HH:MI:SS') from dual;
    select 'Database Name : '||name from sys.v_$database;
    set pages 1000
    SELECT DISTINCT
    O.OBJECT_NAME,
    SH.USERNAME,
    SH.SID,
    SW.USERNAME,
    SW.SID,
    DECODE(LH.LMODE,
    1, 'null',
    2, 'row share',
    3, 'row exclusive',
    4, 'share',
    5, 'share row exclusive',
    6, 'exclusive')
    FROM DBA_OBJECTS O,
    V$SESSION SW,
    V$LOCK LW,
    V$SESSION SH,
    V$LOCK LH
    WHERE LH.ID1 = O.OBJECT_ID
    AND LH.ID1 = LW.ID1
    AND SH.SID = LH.SID
    AND SW.SID = LW.SID
    AND SH.LOCKWAIT IS NULL
    AND SW.LOCKWAIT IS NOT NULL
    AND LH.TYPE = 'TM'
    AND LW.TYPE = 'TM'
    prompt Press Enter to continue ...
    pause
    prompt ************************************************************
    prompt *** Object Lock Information ***
    prompt ************************************************************
    SELECT
    A.OBJECT_NAME,
    A.OWNER,
    C.SERIAL#,
    B.OBJECT_ID,
    B.SESSION_ID,
    B.ORACLE_USERNAME,
    B.OS_USER_NAME,
    B.PROCESS,
    DECODE(B.LOCKED_MODE,
         0,'None',
    1,'Null',
         2,'Row-S (SS)',
         3,'Row-X (SX)',
         4,'Share',
         5,'S/Row-X (SSX)',
         6,'Exclusive') LMODE
    FROM DBA_OBJECTS A, V$LOCKED_OBJECT B, V$SESSION C
    WHERE A.OBJECT_ID = B.OBJECT_ID AND C.SID = B.SESSION_ID
    ORDER BY A.OWNER, A.OBJECT_NAME, C.SERIAL#
    Joel P�rez

  • Backup everything except the system tablespace

    Is there a way to backup everything except the system tablespace without having to specify every individual tablespace?
    version is 10.1.0.5 on HP-UX itanium.
    The reason for this is the database was upgraded from 7.3.4->8i->10.1.0.5 and we are now migrating to using RMAN instead of user managed backups however we have encountered a bug when backing up index blocks in the system tablesapce this only impacts compressed backupsets so If I can exlude the system tablespace I can run two backups one uncompressed that captures the system tablespace then another that captures everything else. I'd really like to avoid specifying the tablespaces in a script as it then introduces the possibility that a new tablespace is added and isn't included in the backups.

    Unfortunatly this database is used by a third party application and the aplpication vendor only supports 10.1.0.5 at the moment, plans are to upgrade next year and tidy up the number of tablespaces at the same time.
    looks like I'll have to backup the system tablespace uncompressed and then all the other tablespaces as a compressed backupset and setup an alert on files not backed up.

  • Missing datafile belonging to SYSTEM tablespace

    Hi All,
    Our dev db server is crashed today as some datafiles belonging to Oracle were deleted by mistake from a developer (I believe to recover some space from server).
    The major hit is to SYSTEM tablespace as the datafile belonging to this tbs is deleted.
    For other tablespaces dev team can easily create as most them are index tablespaces that can be rebuild through scripts. All the data tablespace were saved at different directory so no impact.
    There is no file system backup schedule for this box and only backup is RMAN cold backup for DB and that is of last Tuesday evening and in between dev team has loaded a good amount of data.
    Now please suggest if I can recover the data from datafiles I have with me, I have a current copy of Controlfile with me. I am using Oracle 9.2.0.6 on Linux AS4.
    Thank you.
    Bhupinder

    Under this circumstances, if you mean 'cold backup' as a synonym of no archivelog' if you then what you will be able to do is just to completely restore the database to the backup time and open it, you will loose all changes from the time of backup to the point of failure. If you have a mean to restore data from logical backups that'll be all you will be able to do. Unfortunately system is a critical tablespace and it must be complete and fully recovered at the open database time.
    There are people who underestimate the value of a DRP scenario for development environments. This is valid just as long as there are means to restore data in case of failure and if the development team doesn't see their schedule compromised in case of failure.
    ~ Madrid

  • System Tablespace Usage

    Hi to all,
    I am a bit new to DBA admin and have was wondering how I can see what size each table is in the System Tablespace and list them in order of size?
    Thanks to all that reply

    sybrand_b wrote:
    select t.owner, t.table_name, s.bytes/1024 kb
    from dba_segments s inner join dba_tables t
    on (s.segment_name = t.table_name)
    order by 3 desc;
    Wrong.
    Joiining dba_tables to dba_segments eliminates information about lots of things that the user may want to see, for example:
    <ul>
    Index organized tables - their data segments have an index component and an overflow component, and only the overflow appears from this query.
    Nested tables (holding data from tables with columns of type table) disappear from this view
    Tables in clusters - the segment_name is the cluster name (and the clusters in the system tablespace can be big).
    LOB segments - shouldn't space due to the LOB columns in the tables be reported as well ? They don't show up in dba_tables, so will disappear from this report.
    </ul>
    To the OP.
    If you want detailed information about space usage in the SYSTEM tablespace it's not a trivial task. A starting point is simply to list the segments allocated in the tablespace. If you want to drill down from their, you need to know what the segment type represents and where it comes from. For more detail you may then want to consider how much of the space inside the segment has been used and how much may have been overallocated.
    Start with something simple like:
    column segment_name format a32
    select
         owner, segment_name, segment_type, bytes/1024 kb
    from
         dba_segments
    where
         tablespace_name = 'SYSTEM'
    order by
         kb desc,
         owner
    ;Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    "There's no sense in being precise when you don't even know what you're talking about"
    John von Neumann                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Why is my SYSTEM tablespace not freeing space?

    Oracle 9.2.0.4.0 (64 bit) on Solaris 9
    I have around 50 (similar) schemas on my database (each schema has 15 stored proc packages). This morning I saw the SYSTEM tablespace has only 1.5MB free (normally it has 10MB free).
    Since I am running very low on physical OS disk, I decided to drop 5 unwanted schemas.
    I was hoping that it will free 3 – 5 MB of SYSTEM space, since procedures, functions, packages, and triggers resides in the SYSTEM tablespace.
    But this did not happen after dropping 5 schema I still have 1.5MB free, I did not even get a meg. Why is that, am I missing someting?
    I will solve my disk problem some other way, but[b] I am now very interested in finding out why I did not get more free space from Oracle after dropping schemas that had many packages.
    Thanks in advance if you have some info for me.
    Regards, Nazrul Islam

    Dropping users will not free any space in system tablespace (not that you will see in dba_free_space, anyway) unless those users have segments (i.e. tables, indexes, clusters etc) stored in system. The packages owned by the users you dropped are stored in rows in various tables in the data dictionary. When you drop the user, Oracle essentially does something like:
    DELETE FROM obj$
    WHERE owner# = < user_id of the user beign dropped >The space for these rows is allocated in existing extents in obj$ and the other tables, just like any other data in the database. The space freed by the delete remains allocated to the table.
    HTH
    John

  • Error while transporting database index into quality system

    Hello,
    I am getting an error while transporting a new index in quality system.
    I have created a new index for table VBFA in TRD and activity the object without errors. I even adjusted the database table using database utility.
    While transporting the request there was a strange error "R3TRTABLVBFA was repaired in this system".
    I retransported the objects using a new request. However I still got the same error.
    Please help.

    Navin,
    No idea about the error you have mentioned but check the SAP Notes 185530 and see if you can avoid creating an index.In this Notes it is clearly mentioned on how to use VBFA table without any performance issues.
    K.Kiran.

Maybe you are looking for