oracle table fragmentation

Ползвам TOAD 7.6 и ми стана интересно при анализирането на единия tablespace (X) на базата ми показва таблицата (Y) с 64% фрагментация.
Следват storage параментрите таблицата Y:
Total Size :1478492160
Initial Ext.: 943718400
Next Ext.: 31457280
% Inc:0
PCT_FREE:10
PCT_USED:85
INI_TRANS:1
MAX_TRANS:255
-------------------
Extents:18
NUM_ROWS 8365830
BLOCKS 179729
EMPTY_BLOCKS 750
AVG_SPACE 897
CHAIN_CNT 0
AVG_ROW_LEN 153
AVG_SPACE_FREELIST_BLOCKS 6678
NUM_FREELIST_BLOCKS 2
DEGREE 1

Има и много добре говоряща картинка обаче не стоплих как да я покажа тук (ако изобщо е позволено).

tablespase (x)
-------------------------------------------------------------

table(Y) 64% avr.frag

-------------------------------------------------------------

table (z) 12% avr.frag
-------------------------------------------------------------

table(Y) 64% avr.frag
-------------------------------------------------------------

Затова ще обясня на кратко : таблицата е разположена на две отделни парчета в tablespace-a (само 2 при този не малък размер) а в документацията на Oracle , обяснението за фрагметация на таблица е - когато таблица е разположена на много отделни не последователни блокове в tablespace (или поне това аз съм разбрал)
Може би трябва да уточня че данните в таблицата да копирани от друга таблица наведнъж а , не са insert-вани за дълъг период от време.
Та питам се аз защо да се получава фрагментация в този случай?

не съм сигурен, че е точно така, но мисля че е станало нещо от сорта. Ти си създал таблицата Y с първоначално разширение 900 мб, обаче преди това вече таблицата Z я е имало в табличното пространство, когато е започнал insert-а Oracle е започнал да си заделя новите разширения по 30 мб един след друг, но в един момент е стигнал до място заето от таблицата Z и така. Значи имам предвид, че си създал Y след това Z, Y e zaela pyrwite 900 мб, след това идва Z и заема еди колко си. Обаче след това почваш да пълниш Y и първоначалното разширение не му стига, обаче разширението на Z е до него.
Това е само предположение.
Таблицата е много голяма, затова ако ти се налага да правиш пълно сканиране на таблицата по-добре я дефрагментирай така да се каже. Това, което сега гледам в Enterprise Manager-а е "Tablespace Map" и след това "Reorganize Segment" или "Reorganize Tablespace", но ти трябва и създаден Management Server.
Друг вариант е да drop-неш таблицата и да я създадеш наново. Сложи и дори още по-голям първоначален extent. Мисля ,че тогава ще е наред.
Сещам се да си направиш нов, достатъчно голям tablespace и в него да оставиш само тази таблица. Това е всъщност един от начините за избягване изобщо на фрагментация, като разделяш различните по големина обекти в съответните им таблични пространства според големината.
Питай каквото се сетиш конкретно, ако знам ще се опитам да помогна.

Ами мнението ти звучи правдоподобно защото тази таблица (z)
наистина е била там преди да се инсерт-ват данните в Y, ще ти пратя на майла 2 снимки -1-вата за която писах, и за tablespace Users. Е там няма никва логика да има фрагментацията по пътя който описваш защото е почти празен tablespace-а а ще видиш кво е положението.

ок, прати ми ги да разгледам, в пощата има достатъчно място

сори, че и аз се вкл. в темата, но сега чета и искам само да вметна нещо - за другото колегата ще се оправи

фрагментацията е нещо почти неизбежно, т.е. не трябва да се плашим от нея, оракъл добре се справя с повечето случаи (особено в по-новите версии). по-страшното е когато имаме фрагментация на данните, а тогава резултатът е неприятното забавяне при работа с тях

сетих се, че навремето писах за това и ако ти е интересно, можеш да видиш
[линк]

БЛАГОДАРЯ , ЩЕ ПОГЛЕДНА

Постави PCTFREE=10 PCTUSED=40.
Направи експорт на таблицата, премахни я, ако няма много сложни указатели към нея.
Можеш да премахнеш таблеспейса и да го съждадеш отново. След това направи импорт на таблицата, като се надявам че по дефаулт юзера ще използва този таблеспайс. Така ще се отървеш от фрагментацията. Дай по-голям начален размер на екстента, така ще имаш по-малко екстенти.
Фрагментация означава, че поради големият брой записи в таблицата и малкият екстент имаш много екстенти.

shvert@fmi.uni-sofia.bg