http___blog.yavor.info__m_201102_1.xml
http___blog.yavor.info__m_201102_lang_en.xml
1.1 1.2 1.3 2.1 3.1 3.2 4.1 5.1 6.1 6.2 7.1 7.2 8.1 9.1 10.1 10.2 10.3 10.4 11.1 12.1 12.2 12.3
Минавайки по „Шипченски проход“ забелязах една лъскава бизнес сграда с гордото наименование „ГРАНД РЕНТ“. И се зачудих… кой ли би наел площи в бизнес център с име „ВЕЛИЧЕСТВЕН НАЕМ“? Предполагам, че са имали предвид точно това значение на думата „рент“, а не другите – дупка, цепнатина, пролука, разрив, несъгласие… Index maintenance при INSERT /*+APPEND*/ Напоследък съвсем го зарязах тоя блог. Калпазанска работа… Не че няма какво да споделя, ама ме мързи да го опиша като хората – хем да има test case, хем да е добре измислен, сакън да не издам нещо от нашия production среди. Ето, в петък наблюдавах нещо интересно, но ще го споделя съвсем кратко. Направихме една празна таблица с идеята да я напълним. Не е съвсем безинтересна – има си първичен ключ (демек има индекс), има си partitions, даже някои от тях са компресирани. После взехме да и наливаме бая данни – няколко стотин милиона реда. Наливането беше както се очаква: INSERT /*+ APPEND PARALLEL(T, 8)*/ INTO... В един момент аз си казах „Малей, колко съм прост… трябваше да я направим без първичния ключ, че да не се мотаме с индекса по време на наливането“ Да ама не. Наблюденията показаха, противно на моето очакване, че първо се наляха данните, ама всичките, после се изгради индекса. За това съдя по размера на сегментите – първо partition-ите на таблицата се раздуха (няколко гигабайта), през това време сегмента на индекса беше само с initial extent-а си. И чак на края сегмента на индекса започна да расте и също стана няколко гигабайта. Пак да отбележа, тук не става дума за CTAS. Сега, имам някои предположения как става това, ама пусти мързел, все ме кара да се оправдавам с многото задачи, дето са ми на главата. Така че оставям размишленията за любознателния читател. Аз само отбелязвам, че не всичко в Oracle е така просто, както си мислим ние.
2.1 2.2 3.1 3.2 4.1 4.2 5.1 6.1 6.2 7.1 7.2 7.3 7.4 8.1
It’s Friday now, and I am watching something interesting. I will share it very briefly. I made an empty table with the idea to fill it. Nothing uninteresting – it has just a primary key (in other words – index), a few partitions, some of them are compressed. Then I began to fill it up with data – a few hundred million rows. I used: INSERT / * + APPEND PARALLEL (T, 8) * / INTO ... At one point it flashed upon me: “Wow, I’ve done it wrong … I had to create the table without a primary key, to skip index maintenance during the data load” Yes and no. My observations showed that, contrary to my expectation, the database first drew the data, all of it, then built the index. I saw this by the size of the segments – first table partitions inflated (several gigabytes), during which time the segment of the index had only its initial extent. And then the segment of the index began to grow and became a few gigabytes. And this is not CTAS – it is INSERT.