Discussions
Categories
- 196.7K All Categories
- 2.2K Data
- 235 Big Data Appliance
- 1.9K Data Science
- 449.8K Databases
- 221.5K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 477 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.8K SQL & PL/SQL
- 21.3K SQL Developer
- 295.4K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.1K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 27 Java Learning Subscription
- 37K Database Connectivity
- 153 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 158 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 393 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 170 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 230 Portuguese
Idx coalesce / shrink usage

DanielD
Member Posts: 119 Blue Ribbon
I decided to test the coalesce/shrink operations on a 62 GB index. (10.2.0.4)
I'd like to speed up things using nologging parallel if possible.
-- This step completed in under 45 minutes
ALTER INDEX UNIUS.IDX_SBA_IN_MAIN_001 COALESCE NOLOGGING PARALLEL 18;
-- This step completed in 3,5 hours, now I am puzzled. The blocks
-- are already packed shouldn't this just release space in like notime ?
ALTER INDEX UNIUS.IDX_SBA_IN_MAIN_001 SHRINK SPACE; -- released 12GB
What's interesting is that actual rebuild of the whole index takes roughly
45 minutes or so. So isn't coalesce/shrink completely useless on big segments
with the only single advantage of not locking the segments?
I'd like to speed up things using nologging parallel if possible.
-- This step completed in under 45 minutes
ALTER INDEX UNIUS.IDX_SBA_IN_MAIN_001 COALESCE NOLOGGING PARALLEL 18;
-- This step completed in 3,5 hours, now I am puzzled. The blocks
-- are already packed shouldn't this just release space in like notime ?
ALTER INDEX UNIUS.IDX_SBA_IN_MAIN_001 SHRINK SPACE; -- released 12GB
What's interesting is that actual rebuild of the whole index takes roughly
45 minutes or so. So isn't coalesce/shrink completely useless on big segments
with the only single advantage of not locking the segments?
Tagged:
Answers
-
Daniel
It's worth reading Richard Foote's blog, eg [Index Rebuild vs Coalesce vs Shrink|http://richardfoote.wordpress.com/2008/02/08/index-rebuild-vs-coalesce-vs-shrink-space-pigs-3-different-ones/].
Richard's blog is a great source of iinformation about indexes, with plenty of examples.
Regards Nigel.
This discussion has been closed.