RAC Basics 3 – DLM, PCM, Ping, Cache Fusion

Първото изискване към една база от данни е да предоставя механизъм за гарантиране на консистентността на данните в нея. Това е по-важно от скорост на обработка лекота на работата.

При „еднопотребителски” системи това е лесно – няма нужда от синхронизация. Всичко се случва серийно и единствената заплаха за интегритета са неочакваните грешки, които могат да се предотвратят с елементарни трназакционни механизми.

Когато БД стане многопотребителска, много процеси трябва да си споделят достъпа до данните и всеки да вижда и променя точно каквото трябва. Недопустимо е един атомарен ресурс (примерно ред от таблица) да бъде променян от два процеса едновременно. Това увеличава значително сложността на транзакционните механизми и поставя изискване от заключвания, които да сериализират достъпа. Някои СУБД и сега не се справят успешно с това и предоставят „груб” lock management (примерно заключване при четене, ескалиране на заключването, понеже е скъп ресурс и т.н.). Въпреки това успяват да гарантират консистентност, макар и на цената на намалена скалируемост. Едно от най-гениалните и печеливши парчета в кода на Oracle е страхотното управление на транзакции (родено в дебрите на Oracle 4!).

За да се клъстеризира една БД вече трябва още едно ниво на управление на ресусрите. Това е т.нар. Distributed Lock Manager. Той гарантира, че един обект (примерно блок с данни) може в даден момент да бъде променян само от един възел в клъстера. Това е цяло ново ниво на сложност. DLM няма нищо общо с транзакциите на потребителите. Напълно допустимо е в един блок да има ред, заключен от процес (сесия) работеща на node 1 докато самия блок в даден момент е заключен от node 4.

DLM управлява (основно) блокове в buffer cache. В не-клъстерна среда, ако един процес на един има нужда да прочете или промени даден блок, той поглежда дали е наличен в buffer cache (виж „Четене на данни в Oracle“). Ако не е, прочита го от диска, променя го и готово. Ако някой друг го е променил преди това, то или промените са в Buffer cache (и се работи директно там), или са записани на диска и ще бъдат прочетени.

В клъстерна среда всеки възел си има свой buffer cache. Следователно имаме реална възможност един блок да бъде прочетен и променен от друг възел. В такъв случай дори ако имаме негово старо копие в локалния buffer cache, ще получим неконсистентен изглед на данните. За да се избегне този проблем се въвежда т.нар. PCM (Parallel Cache Management).

Има 3 възможни случая на споделен блок.

– read/read. Тук няма конфликт, понеже няма промяна на данните. Възел 1 прочита блока и по този начин става негов собственик. Когато възел 2 иска да го прочете, няма нужда от намеса на PCM

– read/write. Възел 1 е модифицирал блок, който възел 2 иска да прочете. В старите версии на Oracle (преди 8i), възел 1 трябва да запише блока на общия дисков масив, за да може възел 2 да го прочете. Това е т. нар. ping и е най-голямата пречка за производителността на OPS.
В Oracle 8i се въвежда т. нар Cache Fusion Phase 1. Това е механизъм, при който един допълнителен процес (Block Server Process, BSP) изгражда консистентно копие на блока (CU) във възел 1 и го изпраща на възел 2 през interconnect връзката. По този начин се избягва Ping.

– write/write. В този случай възел 2 иска да модифицира блок, който е модифициран от възел 1. Във Oracle 8i при възникване на такъв случай възел 1 трябва да „отключи” блока и да направи ping, за да може възел 2 да го прочете и заключи. Това е сериозна пречка за скалируемост на OLTP системи, в които често се налага един блок да бъде променян от 2 възела. Във Oracle 9i/10g RAC с появата на Cache Fusion Phase 2 това вече е преодоляно. При Cache Fusion Phase 2 през interconnect се предават като CR, така и CUR варианти на блока и се синхронизира успешно работата без Ping.

Повече подробности за начина на действие на Cache Fusion ще има в следващата част от поредциата