RE: PLATINUM technology TSREORG

To provide a foundation for understanding the problem with TSreorg's o inability to fully reorg free space in ORACLE 7.1.x, I will first expl process: Tsreorg unloads all tables into flat files and then drops all the tablespace. Next, it loads all of the objects back in. Dropping th should cause the free space to become recoalesed into one piece -- and with ORACLE 7.0.x. But with 7.1, ORACLE decided to change the frequen which the "smon" process recoaleses free extents. In 7.0, this happen a frequent basis that by the time we drop the tablespace objects and b reloading them, the free space is already recoalesed. In 7.1, the "smo recoaleses much less frequently -- anywhere from 5 to 15 minutes (this is not tunable and ORACLE support could not tell us the frequency). To deal with this problem, in 1.0.18 of Tsreorg, we put in "hack" that is used by many DBA's to recoalese ORACLE6 free space -- t create a table the size of the total free space and then drop it. Thi for one problem, ORACLE ORACLE 7.1.x has a bug (ora bug # 248875) that causes dropped index extents to appear as temporary used extents for a of about an hour after the index was dropped. Of course this prevents on big table" workaround mentioned above from working. We are told by ORACLE that this bug is fixed in 7.1.6 and 7.2. It is important to not aspects of the tablespace reorg are not affected. This includes defrag of used extents, removal of row chaining, removal ofrow migrations, re wasted space, etc. etc... With regard to eventually eliminating the "c table" hack, ORACLE has admitted that there needs to be a way to ask wake-up and perform its duties by non-ORACLE processes. They have not us a release number where this feature will appear yet. Received on Wed May 17 1995 - 00:00:00 CEST