Discussions
Categories
- 385.5K All Categories
- 4.9K Data
- 2.5K Big Data Appliance
- 2.4K Data Science
- 453.4K Databases
- 223.2K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 47 Multilingual Engine
- 606 MySQL Community Space
- 486 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.2K ORDS, SODA & JSON in the Database
- 585 SQLcl
- 4K SQL Developer Data Modeler
- 188K SQL & PL/SQL
- 21.5K SQL Developer
- 46 Data Integration
- 46 GoldenGate
- 298.4K Development
- 4 Application Development
- 20 Developer Projects
- 166 Programming Languages
- 295K Development Tools
- 150 DevOps
- 3.1K QA/Testing
- 646.7K Java
- 37 Java Learning Subscription
- 37.1K Database Connectivity
- 201 Java Community Process
- 108 Java 25
- 22.2K Java APIs
- 138.3K Java Development Tools
- 165.4K Java EE (Java Enterprise Edition)
- 22 Java Essentials
- 176 Java 8 Questions
- 86K Java Programming
- 82 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 208 Java User Groups
- 25 JavaScript - Nashorn
- Programs
- 667 LiveLabs
- 41 Workshops
- 10.3K Software
- 6.7K Berkeley DB Family
- 3.6K JHeadstart
- 6K Other Languages
- 2.3K Chinese
- 207 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 474 Portuguese
corrupted indexes

ski123
Member Posts: 371 Blue Ribbon
Oracle 9.2. We have a job running slow suddenly. Normal run time is 2 hours, now it is 6 hours. The data volume is the same. we are wondering if the indexes is corrupted. How to find corrupted indexes?
Thanks
S.
Thanks
S.
Answers
-
Unless there is a pile of information that allowed you to conclude that a slow process was the result of a corrupt index, I would strongly suspect that you don't have a corrupt index. Or if you do, that it is unrelated to your performance problem.
Let's start at the beginning-- why is the process slow?
- Do you have a trace of the session or a statspack report from a good run and from a slow run? What are the differences?
- What is the job doing?
- Did any query plans change?
- What is taking up most of the 6 hours the process is running?
Justin -
Hi,
Before doing this I would have always checked whether the explain plan it is taking is the best explain plain, and there are no waits for the session which has slowed down.
Then only I would have followed Oracle MetaLink note 122008.1 to rebuild the index
Regards
Anurag Tibrewal -
Thank you very much. I am looking at stats report.
S. -
Run AWR and get the last AWR Report when it was good / bad.
Look at top 5 events, identify the sql's during good / bad times. If SQL's are executing at the same speed then problem lies somewhere else.
Such a drastic slowdown is probably external to the Database.
Was there any change environmental or otherwise. Any stats change ? -
Hi Anurag
Interestingly, I mention Metalink Note 122008 a number of times in my Index Seminar as a perfect example of how not+ to determine when to rebuild an index.
Thankfully, Oracle have pulled the error filled note from Metalink and with a bit of luck, it will never resurface again to confuse folk.
Cheers
Richard Foote
http://richardfoote.wordpress.com/ -
Hi Richard,
Speaking of index rebuilds and MetaLink notes, have you seen note #182699.1?
I ask because you are quoted in that note....
-Mark -
Hi Richard,Why do you diss the Oracle documentation, and then fail to show the OP a method that does work?I mention Metalink Note 122008 a number of times in my Index Seminar as a perfect example of how not to determine when to rebuild an index.
That's not very helpful!
In many cases, evaluating an index for rebuilding is a waste of time.
It can take more reources to evaluate whether an index needs rebuilding than to actually rebuild it! Done properly, index rebuilding is 100% safe, and recommended by Oracle Corporation. . . .
http://www.dba-oracle.com/art_index1.htm
Oracle's index rebuilding guidelines appear in Metalink note 77574.1 (dated April 2007) recommends that indexes be periodically examined to see if they are candidates for an index rebuild:
“When an index is skewed, parts of an index are accessed more frequently than others. As a result, disk contention may occur, creating a bottleneck in performance.
It is important to periodically examine your indexes to determine if they have become skewed and might need to be rebuilt.”Interestingly, Oracle DBA Jim Spath has shown that regular rebuilding of high DML indexes should be scheduled on a regular basis:Thankfully, Oracle have pulled the error filled note from Metalink
https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/8750%3Fpage%3Dlast
“This index should be reorganized on a regular basis. . .
What is happening here is the index is becoming unbalanced through constant inserts and deletes.
Over time, the space the index occupies will continue to grow though there may be zero rows at the time the system starts and stops.
Each deleted row continues to occupy space in the index segment until a rebuild is done.” -
Sorry.
Oracle indices are B*-tree indices.
By design they can not become unbalanced. EVER!
--------------
Sybrand Bakker
Senior Oracle DBA -
It depends on how you define "unbalanced"!By design they can not become unbalanced. EVER!
When Oracle does a logical delete of a leaf node, the "logical" structire of the b-tree is out of balance. -
Hi Sybrand
Suggesting that "Each deleted row continues to occupy space in the index segment until a rebuild is done” is of course not correct in most cases either as most deleted space is automatically reclaimed and reused by Oracle.
You can only lead a horse to water ...
Cheers
Richard Foote
http://richardfoote.wordpress.com/
This discussion has been closed.