Unusable Indexes

Hi,
I have been experiencing some indexes being unusable due to which queries and jobs taking much longer to finish. As it is very big indices its a big overhead to rebuild those indices on time, so please can anyone help here what may be cause of indices being unusable how to resolve it and factors should we look into to avoid the problem in near future.
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 on Solaris.
Thanks and Regards
Jafar
http://www.oracledbarea.blogspot.com

Hi Jafar,
can anyone help here what may be cause of indices being unusable how to resolve it and Indexes can become invalid or unusable whenever a DBA tasks shifts the ROWID values, thereby requiring an index rebuild.
factors should we look into to avoid the problem in near future.Don't do anything (reorgs) that will cause a change in a rows ROWID.
I have been experiencing some indexes being unusable due to which queries and jobs taking much longer to finish. Yeah, as "unusable", they are not available.
As it is very big indices its a big overhead to rebuild those indices on timeYou can rebuild them super-fast in parallel, if you have an SMP server.
Hope this helps. . .
Donald K. Burleson
Oracle Press author
Author of "Oracle Tuning: The Definitive Reference":
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

Similar Messages

  • How to find unused indexes in oracle 10g r2

    Hi all,
    db:oracle 10.2.0.3
    os:solaris
    i want rebuilt the some of the indexes (due poor performence of db)
    how to find the unused indexes in oracle 10gr2 database.?
    can any one help me out plz.

    kk001 wrote:
    Hi all,
    db:oracle 10.2.0.3
    os:solaris
    i want rebuilt the some of the indexes (due poor performence of db)
    how to find the unused indexes in oracle 10gr2 database.?
    can any one help me out plz.You can use V$OBJECT_USAGE.
    But how you decide need rebuilding indexes?
    How you decide problem related indexes?
    What is exactly your mean "due poor performence of db"? some queries hang/long running or whole system hang or has poor performance?
    In generally do not need rebuilding index(unless specially cases),first give we above questions`s answers.

  • Oracle 10.2.0.3.0 - impdp - Unusable index exists on unique/primary ...

    Hi All,
    Oracle 10.2.0.3.0 - during impdp the following failure appears:
    Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
    ORA-39083: Object type CONSTRAINT failed to create with error:
    ORA-14063: Unusable index exists on unique/primary constraint key
    Failing sql is:
    ALTER TABLE "MY_SCHEMA"."MY_TABLE" ADD CONSTRAINT "MY_TABLE_PK" PRIMARY KEY ("ID")
    USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255
    STORAGE(INITIAL 1048576 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
    TABLESPACE "MY_TBS"
    Question:
    The dump file doesn't contain index tree, and impdp should just create index(es) as it appears in the metadata information.
    So what's the point to flush this error?

    Yes, the index is appearing on the dba_indexes table, however its state is 'UNUSABLE'.
    It looks impdp takes its state from origin metadata, puts into destination, and even is not trying to rebuild it.
    Of course, after running ALTER INDEX REBUILD its status was changed to VALID.
    So, what's the point impdp tells about its state? It can be hundreds of unusable indexes, why it's not just rebuilding it?

  • SQL Loader direct path loads and unusable indexes

    sorry about all the questions. I am researching several issues. I am reading the Utilities document. It says that in certain circumstances indexes will become unusable. I have some questions about my scenario.
    1. tables partitioned by range
    2. local indexes
    3. all tables have 1 primary key and other indexes are non-unique
    4. all sql loads will go into the most recent partition
    5. users will be querying tables while sql loader is occurring
    6. only one sql loader session will run per table
    7. no foreign keys, triggers, or other constrants other than primary keys.
    The docs are not clear. Do I have a concern about unusable indexes with direct path loads? Will indexes function while the sql loader direct path is occurring(this I can't test since I have small data files now and they load fast, but I will have larger ones in production).
    My understanding is that Extertnal tables using Insert append is exactly the same as sql loader direct path load. Is this true?

    if you dont have anything productive to say how about you don't post at all? you have made ignorant posts like this for years.
    as far as reading the docs what do you think "the docs are not clear" means? By the docs I am referring to the utilities document.
    As far as version number its 10.2 and I forgot that. However, it does not appear that sql loader has really changed all that much over the last few versions.
    Finally I plan on testing it out and its more than a 2 minute test. I wanted to make sure I don't miss anythng in my tests.
    don't respond to any threads or posts I make from now on.

  • How to find out unused Indexes (regardless of restarts of server or database)?

    Hello colleagues,
    do you know how to get list of unused indexes regardless of restarts of MS-SQL-Server or Database?
    Because (if I understand correctly to information in
    BOL ) all content of dynamic management view sys.dm_db_index_usage_stats is deleted during restart of MS-SQL-Server or Detach Database.
    Due to when I use my next script (to generate report with list of unused indexes) immediately (or after short time) after restart of MS-SQL-Server it contains misleading/confusing information.
    USE [AdventureWorks]
    GO
    DECLARE @CurrDate as varchar(10), @CurrTime as varchar(5), @DatePartsSeparator as char(1), @EmptyDate as smalldatetime;
    SET @DatePartsSeparator = '/';
    SET @CurrDate = RIGHT ('0' + CONVERT(varchar,DATEPART (day,GETDATE())), 2);
    SET @CurrDate = @CurrDate + @DatePartsSeparator;
    SET @CurrDate = @CurrDate + RIGHT ('0' + CONVERT(varchar,DATEPART (month,GETDATE())), 2);
    SET @CurrDate = @CurrDate + @DatePartsSeparator;
    SET @CurrDate = @CurrDate + CONVERT(varchar,DATEPART (year,GETDATE()));
    SET @CurrTime = RIGHT ('0' + CONVERT(varchar,DATEPART (hour,GETDATE())), 2);
    SET @CurrTime = @CurrTime + ':';
    SET @CurrTime = @CurrTime + RIGHT ('0' + CONVERT(varchar,DATEPART (minute,GETDATE())), 2);
    SET @EmptyDate = CONVERT(smalldatetime, '01' + @DatePartsSeparator + '01' + @DatePartsSeparator + '2000');
    SELECT SERVERPROPERTY('servername') AS [Server]
    , DB_NAME(s.database_id) AS [Database]
    , o.type_desc [ObjectType]
    , o.name AS [Object]
    , i.name AS [Index]
    , (user_seeks + user_scans + user_lookups) AS Reads
    , user_updates AS Writes
    , ((SELECT SUM(p.rows) FROM sys.partitions p WHERE p.index_id = s.index_id AND s.object_id = p.object_id) / 100) AS [Rows(1000)]
    , CASE
    WHEN s.user_updates < 1 THEN 100
    ELSE CAST(1.00 * (s.user_seeks + s.user_scans + s.user_lookups) / s.user_updates AS decimal (12,5))
    END AS Reads_per_Write
    , (SELECT TOP 1 luu.[Last_User_Usage] FROM (
    SELECT COALESCE(s.last_user_lookup, @EmptyDate) AS [Last_User_Usage]
    UNION
    SELECT COALESCE(s.last_user_scan, @EmptyDate) AS [Last_User_Usage]
    UNION
    SELECT COALESCE(s.last_user_seek, @EmptyDate) AS [Last_User_Usage]
    ) AS luu ORDER BY luu.[Last_User_Usage] DESC) AS [Last_User_Usage]
    , COALESCE(s.last_user_update, @EmptyDate) AS [Last_User_Update]
    , CASE WHEN i.is_disabled = 0 THEN 'N' ELSE 'Y' END AS [Disabled]
    , i.index_id
    , o.create_date AS [Index_Created]
    , o.modify_date AS [Index_Modified]
    , u.name AS [Index_Owner]
    , @CurrDate AS [This_Report_Created]
    , @CurrTime AS [This_Report_Created_Time]
    , CONVERT(CHAR(40), SUSER_SNAME()) AS [This_Report_Created_by_User]
    , 'DROP INDEX ' + QUOTENAME(i.name) + ' ON ' + QUOTENAME(DB_NAME(s.database_id)) + '.' + QUOTENAME(c.name) + '.' + QUOTENAME(OBJECT_NAME(s.object_id)) as 'drop statement'
    FROM sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i ON i.index_id = s.index_id AND s.object_id = i.object_id
    INNER JOIN sys.objects o ON s.object_id = o.object_id
    INNER JOIN sys.schemas c ON o.schema_id = c.schema_id
    LEFT OUTER JOIN sys.database_principals u ON OBJECTPROPERTY ( o.object_id , 'OwnerId' ) = u.principal_id
    WHERE OBJECTPROPERTY(s.object_id,'IsUserTable') = 1
    AND s.database_id = DB_ID()
    AND i.type_desc = 'nonclustered'
    AND i.is_primary_key = 0
    AND i.is_unique_constraint = 0
    AND o.type IN ('U','V')
    AND o.is_ms_shipped = 0
    AND (SELECT SUM(p.rows) FROM sys.partitions p WHERE p.index_id = s.index_id AND s.object_id = p.object_id) > 10000
    ORDER BY Reads;
    GO
    __________________________________________________________ If isn't above described anything, the following applies: Technical details: * OS: Windows Server v2008-R2, English, Enterprise Edition, x64, SP1 ** My User-Account is member of 'Administrators'
    local security group. * MS-SQL-Server: v2008-R2, English, Enterprise Edition, x64, SP1 ** My User-Account is member of 'SysAdmin' db-role.

    Hi,
    You are right. The sys.dm_db_index_usage_stats DMV tells how often and to what extent indexes are used.
    Please check the unused section in the below article to find the unused indexes:
    Uncover Hidden Data to Optimize Application Performance
    http://msdn.microsoft.com/en-us/magazine/cc135978.aspx#S5
    In addition, you can also use Database Engine Tuning Advisor to verify if you have too many indexes. DTA can easily find the bad indexes and provide the recommendation for action.
    Reference:
    http://blogs.technet.com/b/sql_server_isv/archive/2011/04/08/fundamentals-running-database-engine-tuning-advisor-and-selecting-indexes.aspx
    Hope it helps.
    Tracy Cai
    TechNet Community Support

  • EAR4 - Gathering Statistics, unusable indexes and more

    Hi,
    Some feedback on statistics:
    1. When choosing a table -> Statistics -> gather Statistics, the minimum is to have a CASCADE option (so all the indexes will be analyzed too). I think it should be the deafult! This way there is a chance that the developers will have good statistics...
    As a bonus, an advanced tab with the rest of the options might be nice, when you have time.
    2. When choosing to gather statistics on an index, you should you dbms_stats and not ALTER INDEX... COMPUTE STATISTICS which is a deprecated syntax.
    And about indexes:
    1. When looking at the index tab of a table, unusable indexes should be visibly different - maybe just color the status column. Well, any color-coding can help to gain more infomation very fast (index types and index status). Well, I guess the same goes for disabled triggers, disabled constraints etc...
    2. When right-clicking an index in an index tab of a table, the only option is export, which makes no sense. Could you replace it with the six relevant index options, just like when we right click an index in the side bar (drop, rebuild, rename, make unusable...)
    Well, same goes for the triggers tab of a table - when right-clicking a trigger give us the trigger actions(enable/disable, drop...), not export.
    my two cents,
    Ofir

    When Choose a partitioned table from the tables list (tree view on the left), I have many tabs with details (Columns, data, indexes,etc).
    1. The last tab, SQL, doesn't generate any CREATE TABLE sql at all for the simple partition table I created (10g Release 2 on windows 2000, raptor 4.1, a table with a single partition).
    2. There is no way to see the partitions definitions - for example, the list of partitions and their ranges (or list values). I would like to have another tab for partitioned table with that information (from all_tab_partitions). Also, how can I easily see the type of partitioning and the partition key of the table?
    3. Also in the builtin reports, there is no way to get that data. The only report about partitioned tables that I see is Table -> Organization -> Partitioned -> Partitioned Tables, that only provide owner, table_name, maybe tablespace and logging (blank in my case).. I think:
    a. You should rewrite the report to use dba/all_part_tables - with columns like partitioning_type, subpartitioning_type, partition_count etc.
    b. add a report about the partition key columns per partitioned table from dba_part_key_columns.
    4. When adding an index to a partitioned table, I can't choose local/global index. The index is always created as a global index. For example, can't create bitmap index on partitioned tables because they must be local.
    Ofir

  • Rebuild unusable indexes

    Hi,
    I am creating a patch for re-building unusable indexes, after splitting partition on a table.
    1. I am spooling the following alter constructs based on dba_indexes:
    select 'alter index '||owner||'.'||index_name||' rebuild online ;' from dba_indexes
    where status = 'UNUSABLE' ;
    My question is: my indexes are listed in dba_indexes and not in user_indexes.
    Am I correct to look in dba_indexes for unusable indexes? What's the difference between dba_indexes and user_indexes?
    2. After splitting a partition on a table I am doing the following:
    - compile invalid objects
    - rebuild unusable indexes
    Do I need to do fix anything else after splitting a partition?
    Thank you.

    if your indexes are not on the USER_INDEXES it means you are trying to rebuild someone else's indexes. So you should have privileges for that. If you are the DBA, or were properly granted privileges, then you can do it.
    Automatic compilation takes place for the invalid database objects in case a DDL took place, and as long as the object signature has not changed the procedures will successfully compile, but you can proactively compile them either way, this will save you time when the related procedure will be executed.
    unless the original motivation relates to something else, it is ok if you want to split partitions, but if you are required to perform this in batch this would let me know you are not aware of the system growth, so technically speaking it is fine, but from the capacity planning point of view, IMO, you should do more work to forecast partition growth requirements.
    ~ Madrid
    http://hrivera99.blogspot.com

  • How to check unusable index

    Hi all
    I am getiing error
    Index ORVETL.NU_1_761 or some [sub]partitions of the index have been marked unusable
    How to check index which is unusable (Partition , non partition ALL)
    Pl help me

    I dont know the query it is user running when i got i will update
    alert log plz
    ORACLE Instance IDEARADB - Can not allocate log, archival required
    Sun Jun 20 13:54:03 2010
    Thread 1 cannot allocate new log, sequence 44150
    All online logs needed archiving
    Current log# 2 seq# 44149 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 13:54:08 2010
    Thread 1 advanced to log sequence 44150 (LGWR switch)
    Current log# 1 seq# 44150 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 13:56:47 2010
    Thread 1 advanced to log sequence 44151 (LGWR switch)
    Current log# 3 seq# 44151 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 14:00:34 2010
    Thread 1 advanced to log sequence 44152 (LGWR switch)
    Current log# 2 seq# 44152 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 14:06:55 2010
    Thread 1 advanced to log sequence 44153 (LGWR switch)
    Current log# 1 seq# 44153 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 14:09:31 2010
    Thread 1 advanced to log sequence 44154 (LGWR switch)
    Current log# 3 seq# 44154 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 14:12:07 2010
    Thread 1 advanced to log sequence 44155 (LGWR switch)
    Current log# 2 seq# 44155 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 14:14:30 2010
    Thread 1 advanced to log sequence 44156 (LGWR switch)
    Current log# 1 seq# 44156 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 14:17:09 2010
    Thread 1 advanced to log sequence 44157 (LGWR switch)
    Current log# 3 seq# 44157 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 14:19:42 2010
    Thread 1 advanced to log sequence 44158 (LGWR switch)
    Current log# 2 seq# 44158 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 14:22:19 2010
    Thread 1 advanced to log sequence 44159 (LGWR switch)
    Current log# 1 seq# 44159 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 14:24:45 2010
    Thread 1 advanced to log sequence 44160 (LGWR switch)
    Current log# 3 seq# 44160 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 14:27:15 2010
    Thread 1 advanced to log sequence 44161 (LGWR switch)
    Current log# 2 seq# 44161 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 14:29:45 2010
    Thread 1 advanced to log sequence 44162 (LGWR switch)
    Current log# 1 seq# 44162 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 14:32:21 2010
    Thread 1 advanced to log sequence 44163 (LGWR switch)
    Current log# 3 seq# 44163 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 14:34:58 2010
    Thread 1 advanced to log sequence 44164 (LGWR switch)
    Current log# 2 seq# 44164 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 14:37:35 2010
    Thread 1 advanced to log sequence 44165 (LGWR switch)
    Current log# 1 seq# 44165 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 14:40:08 2010
    Thread 1 advanced to log sequence 44166 (LGWR switch)
    Current log# 3 seq# 44166 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 14:43:52 2010
    Thread 1 advanced to log sequence 44167 (LGWR switch)
    Current log# 2 seq# 44167 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 14:50:46 2010
    Thread 1 advanced to log sequence 44168 (LGWR switch)
    Current log# 1 seq# 44168 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 14:51:47 2010
    Thread 1 advanced to log sequence 44169 (LGWR switch)
    Current log# 3 seq# 44169 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 14:53:05 2010
    Thread 1 advanced to log sequence 44170 (LGWR switch)
    Current log# 2 seq# 44170 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 14:56:59 2010
    Thread 1 advanced to log sequence 44171 (LGWR switch)
    Current log# 1 seq# 44171 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 15:07:42 2010
    Thread 1 advanced to log sequence 44172 (LGWR switch)
    Current log# 3 seq# 44172 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 15:17:31 2010
    Thread 1 advanced to log sequence 44173 (LGWR switch)
    Current log# 2 seq# 44173 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 15:24:32 2010
    Thread 1 advanced to log sequence 44174 (LGWR switch)
    Current log# 1 seq# 44174 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 15:32:49 2010
    Thread 1 advanced to log sequence 44175 (LGWR switch)
    Current log# 3 seq# 44175 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 15:41:28 2010
    Thread 1 advanced to log sequence 44176 (LGWR switch)
    Current log# 2 seq# 44176 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 15:45:28 2010
    Index ORVETL.NU_1_761 or some [sub]partitions of the index have been marked unusable
    Sun Jun 20 15:45:49 2010
    Index ORVETL.NU_2_761 or some [sub]partitions of the index have been marked unusable
    Sun Jun 20 15:48:24 2010
    Index ORVETL.NU_1_762 or some [sub]partitions of the index have been marked unusable
    Sun Jun 20 15:49:03 2010
    Index ORVETL.NU_2_762 or some [sub]partitions of the index have been marked unusable
    Sun Jun 20 15:51:11 2010
    Thread 1 advanced to log sequence 44177 (LGWR switch)
    Current log# 1 seq# 44177 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 16:01:10 2010
    Thread 1 advanced to log sequence 44178 (LGWR switch)
    Current log# 3 seq# 44178 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 16:06:20 2010
    Index ORVETL.NU_1_751 or some [sub]partitions of the index have been marked unusable
    Sun Jun 20 16:11:04 2010
    Thread 1 advanced to log sequence 44179 (LGWR switch)
    Current log# 2 seq# 44179 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 16:16:40 2010
    Index ORVETL.NU_1_753 or some [sub]partitions of the index have been marked unusable
    Sun Jun 20 16:17:54 2010
    Index ORVETL.NU_2_753 or some [sub]partitions of the index have been marked unusable
    Sun Jun 20 16:20:28 2010
    Thread 1 advanced to log sequence 44180 (LGWR switch)
    Current log# 1 seq# 44180 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 16:30:11 2010
    Thread 1 advanced to log sequence 44181 (LGWR switch)
    Current log# 3 seq# 44181 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 16:38:45 2010
    Thread 1 advanced to log sequence 44182 (LGWR switch)
    Current log# 2 seq# 44182 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 16:40:40 2010
    Memory Notification: Library Cache Object loaded into SGA
    Heap size 54067K exceeds notification threshold (51200K)
    Sun Jun 20 16:41:08 2010
    Memory Notification: Library Cache Object loaded into SGA
    Heap size 54016K exceeds notification threshold (51200K)
    Details in trace file /oracle/oracle/Oracle_10gr2_DB/admin/IDEARADB/udump/idearadb_ora_1081756.trc
    Sun Jun 20 16:41:17 2010
    Thread 1 advanced to log sequence 44183 (LGWR switch)
    Current log# 1 seq# 44183 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 16:41:32 2010
    Memory Notification: Library Cache Object loaded into SGA
    Heap size 54066K exceeds notification threshold (51200K)
    Details in trace file /oracle/oracle/Oracle_10gr2_DB/admin/IDEARADB/udump/idearadb_ora_1081756.trc
    Sun Jun 20 16:41:56 2010
    Memory Notification: Library Cache Object loaded into SGA
    Heap size 54015K exceeds notification threshold (51200K)
    Details in trace file /oracle/oracle/Oracle_10gr2_DB/admin/IDEARADB/udump/idearadb_ora_1081756.trc
    Sun Jun 20 16:49:45 2010
    Thread 1 advanced to log sequence 44184 (LGWR switch)
    Current log# 3 seq# 44184 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 16:58:01 2010
    Thread 1 advanced to log sequence 44185 (LGWR switch)
    Current log# 2 seq# 44185 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 17:00:15 2010
    Thread 1 advanced to log sequence 44186 (LGWR switch)
    Current log# 1 seq# 44186 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 17:02:37 2010
    Thread 1 advanced to log sequence 44187 (LGWR switch)
    Current log# 3 seq# 44187 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 17:05:13 2010
    Thread 1 advanced to log sequence 44188 (LGWR switch)
    Current log# 2 seq# 44188 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 17:07:37 2010
    Thread 1 advanced to log sequence 44189 (LGWR switch)
    Current log# 1 seq# 44189 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 17:13:36 2010
    Thread 1 advanced to log sequence 44190 (LGWR switch)
    Current log# 3 seq# 44190 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 17:19:16 2010
    Thread 1 advanced to log sequence 44191 (LGWR switch)
    Current log# 2 seq# 44191 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 17:25:15 2010
    Thread 1 advanced to log sequence 44192 (LGWR switch)
    Current log# 1 seq# 44192 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 17:32:18 2010
    Thread 1 advanced to log sequence 44193 (LGWR switch)
    Current log# 3 seq# 44193 mem# 0: +REDO_LOG/redo03.log
    Sun Jun 20 17:37:41 2010
    Memory Notification: Library Cache Object loaded into SGA
    Heap size 53686K exceeds notification threshold (51200K)
    Sun Jun 20 17:38:02 2010
    Memory Notification: Library Cache Object loaded into SGA
    Heap size 53898K exceeds notification threshold (51200K)
    Details in trace file /oracle/oracle/Oracle_10gr2_DB/admin/IDEARADB/udump/idearadb_ora_1241490.trc
    Sun Jun 20 17:38:21 2010
    Memory Notification: Library Cache Object loaded into SGA
    Heap size 54025K exceeds notification threshold (51200K)
    Details in trace file /oracle/oracle/Oracle_10gr2_DB/admin/IDEARADB/udump/idearadb_ora_1241490.trc
    Sun Jun 20 17:38:40 2010
    Memory Notification: Library Cache Object loaded into SGA
    Heap size 54012K exceeds notification threshold (51200K)
    Details in trace file /oracle/oracle/Oracle_10gr2_DB/admin/IDEARADB/udump/idearadb_ora_1241490.trc
    Sun Jun 20 17:39:21 2010
    Thread 1 advanced to log sequence 44194 (LGWR switch)
    Current log# 2 seq# 44194 mem# 0: +REDO_LOG/redo02.log
    Sun Jun 20 17:45:28 2010
    Thread 1 advanced to log sequence 44195 (LGWR switch)
    Current log# 1 seq# 44195 mem# 0: +REDO_LOG/redo01.log
    Sun Jun 20 17:51:21 2010

  • Unusable index

    Ho can I check whether an index is in usable form or unusable form?

    951472 wrote:
    Ho can I check whether an index is in usable form or unusable form?2 seconds of google and 5 minutes of reading (max) is about all this should take to answer yourself.
    I did the 2 seconds of googling for you
    https://www.google.ca/#hl=en&sclient=psy-ab&q=oracle+check+index+status+unusable&oq=oracle+check+index+status+unusable&gs_l=hp.3..0i22.14507.17456.2.17746.9.9.0.0.0.0.193.1217.1j8.9.0...0.0...1c.vXgdTgh9EFQ&psj=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=5003a84749852bba&biw=853&bih=412
    Cheers,

  • Make unusable index undo

    Hello,
    for deletion I have set the indexes of a table to unstable. But I could not delete: ORA-01502. What a shit. Why did not warn Oracle me? Rebuild is too expensive. Ich will delete, delete, delete. Why must I have a fucking index?
    Is there a faster way to rebuild or to get a state in which I can start deletion?

    We do not know what version you have.
    We do not know what DDL you executed (or why).
    We do not know what error messages you are viewing.
    Not knowing what you did to what it is unlikely anyone is going to be able to help you except, perhaps, to refer you to an anger management class. <g>
    Oracle, the company, assumes that people that use their product read the documentation they spend many millions of dollars to prepare and post online. They expect that when people do things it is with a reasonable understanding of the consequences. This is no different from a car company assuming that you know what the brake pedal is for.
    Calm down and post the information we need to be able to help you.

  • ORA-01502 : index SYS.I_PROCEDURE1 is in unusable state

    Oracle EE 9.2.0.8 on Windows 2003 SP2
    Some SYS tables where moved by mistake with statement : "alter table sys.xxx move tablespace system;"
    This caused some unusable SYS indexes but I cannot rebuild them. Each time I get same error :
    ORA-01502: index 'SYS.I_PROCEDURE1' or partition of such index is in unusable state
    Tracing showed me that some recursive SQL is going on and that fails because of the unusable index I_PROCEDURE1
    This is the recursive sql who fails :
    SQL> select audit$,options from procedure$ where obj#=115;
    ERROR at line 1:
    ORA-01502: index 'SYS.I_PROCEDURE1' or partition of such index is in unusable state
    How do get out of this situation ?
    Have already tried without succes :
    - alter session set skip_unusable_indexes=true;
    - altered some parameters to favor full table scans (optimizer_mode, db_file_multi_block_read_count
    - tried to drop index (same error)
    Thanks.
    Benny Derous

    Are you saying that you cannot rebuild that particular index, or other indexes? It works for me:orcl> alter index sys.i_procedure1 rebuild;
    Index altered.
    orcl> select * from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE    11.2.0.3.0      Production
    TNS for 32-bit Windows: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - Production
    orcl>

  • ORA-01502 error in case of unusable unique index and bulk dml

    Hi, all.
    The db is 11.2.0.3 on a linux machine.
    I made a unique index unusable, and issued a dml on the table.
    Howerver, oracle gave me ORA-01502 error.
    In order to avoid ORA-01502 error, do I have to drop the unique index ,and do bulk dml, and recreate the index?
    Or Is there any other solution without re-creating the unique index?
    create table hoho.abcde as
    select level col1 from dual connect by level <=1000
    10:09:55 HOHO@PD1MGD>create unique index hoho.abcde_dx1 on hoho.abcde (col1);
    Index created.
    10:10:23 HOHO@PD1MGD>alter index hoho.abcde_dx1 unusable;
    Index altered.
    Elapsed: 00:00:00.03
    10:11:27 HOHO@PD1MGD>delete from hoho.abcde where rownum < 11;
    delete from hoho.abcde where rownum < 11
    ERROR at line 1:
    ORA-01502: index 'HOHO.ABCDE_DX1' or partition of such index is in unusable stateThanks in advance.
    Best Regards.

    Hi. all.
    The following is from "http://docs.oracle.com/cd/E14072_01/server.112/e10595/indexes002.htm#CIHJIDJG".
    Is there anyone who can show me a tip to avoid the following without dropping and re-creating an unique index?
    •DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
    Unusable indexes
    An unusable index is ignored by the optimizer and is not maintained by DML. One reason to make an index unusable is if you want to improve the performance of bulk loads. (Bulk loads go more quickly if the database does not need to maintain indexes when inserting rows.) Instead of dropping the index and later recreating it, which requires you to recall the exact parameters of the CREATE INDEX statement, you can make the index unusable, and then just rebuild it. You can create an index in the unusable state, or you can mark an existing index or index partition unusable. The database may mark an index unusable under certain circumstances, such as when there is a failure while building the index. When one partition of a partitioned index is marked unusable, the other partitions of the index remain valid.
    An unusable index or index partition must be rebuilt, or dropped and re-created, before it can be used. Truncating a table makes an unusable index valid.
    Beginning with Oracle Database 11g Release 2, when you make an existing index unusable, its index segment is dropped.
    The functionality of unusable indexes depends on the setting of the SKIP_UNUSABLE_INDEXES initialization parameter.
    When SKIP_UNUSABLE_INDEXES is TRUE (the default), then:
    •DML statements against the table proceed, but unusable indexes are not maintained.
    •DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
    •For non-partitioned indexes, the optimizer does not consider any unusable indexes when creating an access plan for SELECT statements. The only exception is when an index is explicitly specified with the INDEX() hint.
    •For a partitioned index where one or more of the partitions are unusable, the optimizer does not consider the index if it cannot determine at query compilation time if any of the index partitions can be pruned. This is true for both partitioned and non-partitioned tables. The only exception is when an index is explicitly specified with the INDEX() hint.
    When SKIP_UNUSABLE_INDEXES is FALSE, then:
    •If any unusable indexes or index partitions are present, any DML statements that would cause those indexes or index partitions to be updated are terminated with an error.
    •For SELECT statements, if an unusable index or unusable index partition is present but the optimizer does not choose to use it for the access plan, the statement proceeds. However, if the optimizer does choose to use the unusable index or unusable index partition, the statement terminates with an error.Thanks in advance.
    Best Regards.

  • Rebuilding indexes after importing...

    My coworker and I are discussing whether it is necessary, or advised, to rebuild indexes after an import of the schema.
    My thinking is that the index data is put into fresh blocks thereby creating a very flat index tree without any fragmentation.
    But my coworker suspects that perhaps the blocks are built exactly as they existed in the source database.
    I could understand, perhaps, if the refresh were done by using RMAN which copies block by block, but even then I'm not sure.
    Can you help us understand this please?
    Thanks.
    Ed

    Hi,
    Normally, the indexes are build and statistics upfated after the import automatically. You do not ned to generate the statistics after the import until unless you are running very old version of database.
    Regards
    [sfa-dev1:oracle:10.2.0] $ imp help=Y
    Import: Release 10.2.0.4.0 - Production on Fri Nov 13 11:49:56 2009
    Copyright (c) 1982, 2007, Oracle. All rights reserved.
    You can let Import prompt you for parameters by entering the IMP
    command followed by your username/password:
    Example: IMP SCOTT/TIGER
    Or, you can control how Import runs by entering the IMP command followed
    by various arguments. To specify parameters, you use keywords:
    Format: IMP KEYWORD=value or KEYWORD=(value1,value2,...,valueN)
    Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N
    or TABLES=(T1:P1,T1:P2), if T1 is partitioned table
    USERID must be the first parameter on the command line.
    Keyword Description (Default) Keyword Description (Default)
    USERID username/password FULL import entire file (N)
    BUFFER size of data buffer FROMUSER list of owner usernames
    FILE input files (EXPDAT.DMP) TOUSER list of usernames
    SHOW just list file contents (N) TABLES list of table names
    IGNORE ignore create errors (N) RECORDLENGTH length of IO record
    GRANTS import grants (Y) INCTYPE incremental import type
    INDEXES import indexes (Y) COMMIT commit array insert (N)
    ROWS import data rows (Y) PARFILE parameter filename
    LOG log file of screen output CONSTRAINTS import constraints (Y)
    DESTROY overwrite tablespace data file (N)
    INDEXFILE write table/index info to specified file
    SKIP_UNUSABLE_INDEXES skip maintenance of unusable indexes (N)
    FEEDBACK display progress every x rows(0)
    TOID_NOVALIDATE skip validation of specified type ids
    FILESIZE maximum size of each dump file
    STATISTICS             import precomputed statistics (always) On 10gR2
    Edited by: skvaish1 on Nov 13, 2009 11:50 AM

  • Too Many Index in a Table

    Dear Gurus,
    I´ve got some performance problems of an especific table called CC_FICHA_FINANCEIRA, the structure of the table is described below:
    NUMBER OF RECORDS: ABOUT 1.600.000
    NAME NULL TYPE
    CD_FUNDACAO NOT NULL VARCHAR2(2)
    NUM_INSCRICAO NOT NULL VARCHAR2(9)
    CD_PLANO NOT NULL VARCHAR2(4)
    CD_TIPO_CONTRIBUICAO NOT NULL VARCHAR2(2)
    ANO_REF NOT NULL VARCHAR2(4)
    MES_REF NOT NULL VARCHAR2(2)
    SEQ_CONTRIBUICAO NOT NULL NUMBER(5)
    CD_OPERACAO NOT NULL VARCHAR2(1)
    SRC NUMBER(15,2)
    REMUNERACAO NUMBER(15,2)
    CONTRIB_PARTICIPANTE NUMBER(15,2)
    CONTRIB_EMPRESA NUMBER(15,2)
    DIF_CONTRIB_PARTICIPANTE NUMBER(15,2)
    DIF_CONTRIB_EMPRESA NUMBER(15,2)
    TAXA_ADM_PARTICIPANTE NUMBER(15,2)
    TAXA_ADM_EMPRESA NUMBER(15,2)
    QTD_COTA_RP_PARTICIPANTE NUMBER(15,6)
    QTD_COTA_FD_PARTICIPANTE NUMBER(15,6)
    QTD_COTA_RP_EMPRESA NUMBER(15,6)
    QTD_COTA_FD_EMPRESA NUMBER(15,6)
    ANO_COMP NOT NULL VARCHAR2(4)
    MES_COMP NOT NULL VARCHAR2(2)
    CD_ORIGEM VARCHAR2(2)
    EXPORTADO VARCHAR2(1)
    SEQ_PP_PR_PAR NUMBER(10)
    ANO_PP_PR_PAR NUMBER(5)
    SEQ_PP_PR_EMP NUMBER(10)
    ANO_PP_PR_EMP NUMBER(5)
    SEQ_PP_PR_TX_PAR NUMBER(10)
    ANO_PP_PR_TX_PAR NUMBER(5)
    SEQ_PP_PR_TX_EMP NUMBER(10)
    ANO_PP_PR_TX_EMP NUMBER(5)
    I think that the indexes of this table can be the problem, there are too many. I will describe them below:
    INDEX COLUMNS
    CC_FICHA_FINANCEIRA_PK CD_FUNDACAO
    NUM_INSCRICAO
    CD_PLANO
    CD_TIPO_CONTRIBUICAO
    ANO_REF
    MES_REF
    SEQ_CONTRIBUICAO
    CD_OPERACAO
    ANO_COMP
    MES_COMP
    CC_FICHA_FINANCEIRA_IDX_002 CD_FUNDACAO
    NUM_INSCRICAO
    CD_PLANO
    CD_TIPO_CONTRIBUICAO
    ANO_COMP
    ANO_REF
    MES_COMP
    MES_REF
    SRC
    CC_FICHA_FINANCEIRA_IDX_006 CD_ORIGEM
    CC_FICHA_FINANCEIRA_IDX_007 CD_TIPO_CONTRIBUICAO
    CC_FICHA_FINANCEIRA_IDX2 CD_FUNDACAO
    ANO_REF
    MES_REF
    NUM_INSCRICAO
    CD_PLANO
    CD_TIPO_CONTRIBUICAO
    CONTRIB_EMPRESA
    CC_FICHA_FINANCEIRA_IDX3 CD_FUNDACAO
    ANO_REF
    MES_REF
    CD_PLANO
    CD_TIPO_CONTRIBUICAO
    SEQ_CONTRIBUICAO
    There are columns that have 4 indexes. Is it right? How is the better way to analyze those indexes?
    Regards...

    Hi,
    You can monitor index usage to know if it used by application.
    See metalink note 136642.1 Identifying Unused Indexes with the ALTER INDEX MONITORING USAGE Command
    Nicolas.

  • Sql -loader and indexes

    Hi
    I'm working with sql-loader in Oracle8. I'm loading a table with one index, ¿can i have any problem with that index?, problems of unusable index or something similar
    Thanks in advance

    If an index is in a direct mode state, it usually means that a direct path sqlload (sqlldr) was run against the underlying table,
    and the indexes were defined at the time of the load.
    If the indexes were left in a direct load state, it means the direct path load failed while re-creating/merging the indexes.
    Any attempt to use such an index will result in ORA-1502:
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96525/e1500.htm#1000531

Maybe you are looking for