Минавайки по „Шипченски проход“ забелязах една лъскава бизнес сграда с гордото наименование „ГРАНД РЕНТ“. И се зачудих… кой ли би наел площи в бизнес център с име „ВЕЛИЧЕСТВЕН НАЕМ“? Предполагам, че са имали предвид точно това значение на думата „рент“, а не другите – дупка, цепнатина, пролука, разрив, несъгласие…
Index maintenance при INSERT /*+APPEND*/
Напоследък съвсем го зарязах тоя блог. Калпазанска работа…
Не че няма какво да споделя, ама ме мързи да го опиша като хората – хем да има test case, хем да е добре измислен, сакън да не издам нещо от нашия production среди.
Ето, в петък наблюдавах нещо интересно, но ще го споделя съвсем кратко.
Направихме една празна таблица с идеята да я напълним. Не е съвсем безинтересна – има си първичен ключ (демек има индекс), има си partitions, даже някои от тях са компресирани.
После взехме да и наливаме бая данни – няколко стотин милиона реда. Наливането беше както се очаква: INSERT /*+ APPEND PARALLEL(T, 8)*/ INTO...
В един момент аз си казах „Малей, колко съм прост… трябваше да я направим без първичния ключ, че да не се мотаме с индекса по време на наливането“
Да ама не. Наблюденията показаха, противно на моето очакване, че първо се наляха данните, ама всичките, после се изгради индекса. За това съдя по размера на сегментите – първо partition-ите на таблицата се раздуха (няколко гигабайта), през това време сегмента на индекса беше само с initial extent-а си. И чак на края сегмента на индекса започна да расте и също стана няколко гигабайта.
Пак да отбележа, тук не става дума за CTAS.
Сега, имам някои предположения как става това, ама пусти мързел, все ме кара да се оправдавам с многото задачи, дето са ми на главата. Така че оставям размишленията за любознателния читател. Аз само отбелязвам, че не всичко в Oracle е така просто, както си мислим ние.