A mai napon új dolgot tanultam az adattárházak teljesítmény-hangolásáról. Szétszedtem egy párhuzamos végrehajtási tervvel futó, parallel DML - t is használó lekérdezést darabokra, mely érzésem szerint a kelleténél tovább futott. Azt találtam, hogy végrehajtás részeredményei viszonylag hamar előállnak, az eredmények táblába írása viszont borzalmasan lassú. További kutakodás után kiderült, hogy a végleges rekordokhoz egy szekvenciából vesz az SQL - em egy sorszámot, ha ezt a műveletet kihagyom, akkor pillanatok alatt lefut a lekérdezésem, ha beveszem akkor a végtelenségig fut.
Kicsit megvizsgálva a szekvenciát, kiderült róla, hogy nocache opcióval lett létrehozva. Ez rögtön rossznak tűnk, úgyhogy beállítottam a szokásos 20 - as értéket a cache - nek, ez azonnali jelentős javulást eredményezett. Arra gyanakodtam, hogy a sorszámok generálása, a sorszám cache feltöltése gátolja a párhuzamosan futó feldolgozó szálakat. Tovább kísérleteztem a cache méret növelésével és azt tapasztaltam, hogy egészen 100000 - es cache méretig újabb jelentős sebesség javulásokat tud előidézni a cache méret emelése. Érzékeltetés képen, a konkrét feldolgozásom végrehajtási ideje két és fél óráról 15 - percre csökkent le a megfelelő cache érték beállítása után.
Egy szó mint száz, adattárház környezetben a szekvenciák cache méretét másként kell méretezni, érdemes leellenőrizni a beállításainkat, mert jelentős gátjai lehetnek a gyors, párhuzamos végrehajtásnak.
Ez bizony fontos dolog. A sorszám generálása mindenképpen szűk keresztmetszet, akár egy saját táblát használ a fejlesztő erre, akár a beépített szekvenciákat használja.
VálaszTörlésA konkurrensen futó végrehajtási szálak mindenképpen várakozni fognak valamennyit, amikor sorbanállnak a következő számért, csak nagyon nem mindegy, hogy ilyenkor a lassú diszken történik valamilyen zárolás, vagy elég csak egy villámgyors memóriaművelet.