When the shit hits tha fan

 Без категория  Коментарите са изключени за When the shit hits tha fan
мар. 232007
 

Използвам този израз в безсилието си да намеря нещо подобно на български. Понякога израза „никое зло не идва само“ е слабичък. И на всеки може да се случи.

Попаднах на следния сценарий за Oracle филм на ужасите. Сюжета е изпъстрен с невероятни, кой от кой по-отвратителни обрати. Разказва се за Howard J. Rogers, един от признатите Oracle database специалисти в световен мащаб. Нещата, които му се случват са поредица от удари на съдбата, които разтърсват DBA-ската ми душа. И да, както писах по-рано, съчувствието изниква много лесно при отрицателните емоции. Едни мравки започват да лазят по гърба ми, душата ми се свива и имам чувството че съм там и се боря. Защото това е реален случай. И аз, с очите си съм виждал как се правят компромис след компромис, временно, докато дойде новия сървър, докато дойдат нови дискове или нещо подобно.

И както писах едва вчера, бекъпите трябва да се ТЕСТВАТ!

Най-тъжното е, че Howard много добре ги знае и разбира тези неща. И пише в своя блог за това. Не обвинявам и бизнеса, неговите шефове, че не са послушали неговите предупреждения.

Просто се случва. На всеки. Това е най-страшното.

 Posted by at 10:21

Имаш ли бекъп?

 Без категория  3 Responses »
мар. 222007
 

Любим цитат

Нямаш backup, докато не си направил restore

Толкова е вярно това твърдение!!! И се повтаря, в книги, в статии, лекции… И въпреки това има адски много отговорни организации, които си позволяват лудостта да правят някакъв бекъп без да го тестват.

И ето, случва се най-лошото. Важна система, публична, обезопасена. Резервен диск с копие на данните. И ленти с backup, които никой не тества.

Една нещастна вечер по грешка са изтрити данните И копието на резервен диск. Няма проблем, ще ги възстановим от лента, обаче… Лентовата библиотека не работи.

Какво следва?

70 души в продължение на няколко седмици работят извънредно, дори и уикендите, за да въведат изгубената информация от хартиените оригинали. 220 000 долара загуби. И след като всичко се нормализира, се прави качествена бекъп стратегия, включваща и периодичен тестов recover.

 Posted by at 17:57
мар. 202007
 

Oracle database 10g R2 постигна нов рекорд за производителност на OLTP БД. Постигнат е резултат от 4 092 799 транзакции в минута. Отбелязан е на сайта на Transaction Processing Performance Council, най-авторитетния източник на performace информация за БД. Резултата освен най-добър като скорост (performance) е и най-добър с отношение цена на транзакция (price/performance) – $2.93. Сред десетте най-бързи в момента има 5 резултата, постигнати с Oracle Database, 4 с IBM DB2 и един, постигнат с Microsoft SQL Server.

Отчитането на резултатите се извършва с независими системи. За отчитане на цената се взимат всички подробности (хардуер на сървъра, хардуер на клиентите, мрежи, кабели, шкафове, сторидж, лиценз за ОС и БД), като се изчислява официалната цена, предоставена от производителя и стандартни отстъпки. Не се допускат „специално договорени цени”.

Системата, на която е постигнат рекордният резултат е HP Integrity Superdome с 64 двуядрени Itaium2 процесора на 1.6 GHz, 2 TB памет, 126 сторидж системи MSA 1500 с общо пространство 320974 GB. Повече подробности за системата – тук

 Posted by at 14:50

TicketPro

 Общи  Коментарите са изключени за TicketPro
мар. 202007
 

Искам да „поздравя” SME за великата идея да поверят на TicketPro Online продажбата на билети за концерта на Iron Maiden.

Великите билетопродавачи, които се имат за „един от световните лидери в областта на продажбата на билети за различни събития – концерти, изложби, театрални постановки, спортни мероприятия, кино и други” имат безкрайно бъгав софтуер, бавен сайт и абсолютно нулево отношение към клиента. Те са един опит за машина за пари. Защо мисля така?

На 12.03.2007 заявих мечтаните билети. Имах известни борби със сайта за online банкиране DskDirect. На 13 преведох успешно парите и застинах в тръпнещо очакване на заветните хартийки…

Според правилата на сайта, след като получат плащането ще ми потвърдят с мейл. Билета се получава до 3 дни. Конкретно за Iron Maiden, обаче, световният лидер, който „предлага на пазара билети за най-големите световни звезди като Роби Уилямс, Ролинг Стоунс, Ю ту, Пинк Флойд, Майкъл Джексън, Маестро Лучано Павароти, Боб Дилън, Дженезис, Дейвид Бауи, Ерик Клептън и много други” се претовари.

На 13.03.2007 пуснаха едно извинително съобщение, в което казват че „До момента има приети над 3000 заявки за закупуване на билети онлайн. Умоляваме всички, направили своята поръчка до днес – 13 март (вторник) – да бъдат търпеливи! Обработката на електронните продажби изисква определено време.

Тикетпро България гарантира, че след извършено плащане и потвърждение за това, всички билети ще бъдат доставени на получателите им най-късно до 22 март (четвъртък).”

За поръчалите по-късно – нищо не се знае. Е, аз не съм от тях, поне… Обаче!

Моята поръчка е направена на 12.03. Изпратил съм парите на 13.03. На 16.03. поръчката ми в сайта още беше в статус „очаква плащане”. Леко се притесних – все пак 180 лв съм изпратил, да не е станала грешка? Започнах да търся в сайта има някакъв телефон за връзка… няма! Никакъв начин за връзка! Единствения мейл се отнася за технически прблеми, info@ticketpro.bg
Там изпратих молба за съдействие. Описах на краткo какъв ми е проблема и помолих да ми дадат координати на някой, който мога да попитам. Може ли някой да се сети какъв отговор получих?

Никакъв.

Абсолютно никакъв!

А днес отново погледнах поръчката си. Да, вече е платена. Дори е получена.

Transaction number: ****
Date&Time: 3/12/2007 2:22:22 PM
Payment: Payment confirmed/Paid
Delivery: Delivery confirmed/picked up

До тук с TicketPro.

* * * * * * * * * * * * * * * * * * * * * * * * * * * *

21.03.2007: Билетите пристигнаха

 Posted by at 9:49

Усмивка на деня

 Общи  Коментарите са изключени за Усмивка на деня
мар. 162007
 

Metalink Note:239100.1
Data Guard Protection Modes Explained

Using SSH port forwarding with compression disabled has a minimal cpu impact. Using with compression enabled also has minimal cpu impact while achieving a significant reduction in network traffic.

Вероятно и двете твърдения са верни – не споря. Забавен е просто начина, по който са написани
🙂

 Posted by at 11:29

RAC Basics – next

 Без категория  Коментарите са изключени за RAC Basics – next
мар. 162007
 

За сега ще задържа поредицата, за да я изчистя и представя качествено на семинара на БГОУГ след месец. Заех се дълбоко с подготовката за лекцията, която ще изнеса там и, за съжаление, не мога паралелно да поддържам формата на написаното в блога . Който иска максимално бързо да разбере как продължава историята – добре дошъл в Пловдив 🙂
А който няма възможност – обещавам веднага след семинара да публикувам следващите части…

 Posted by at 10:44
мар. 162007
 

Зачудил съм се за чувствата и емоциите. И по-точно за съчувствието. Но не това, което официално се изразява по разни поводи (обикновено тъжни). А истинското предаване на чувства. И подозирам, че има някаква неравнопоставеност между положителните и отрицателните емоции.

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

Докато омразата… тя се възприема по всяко време. В каквото и настроение да си, винаги можеш да приемеш, разбереш и почувстваш тези думи (Иван Вазов за поп Кръстьо):

Той биде предаден, и от един поп!
Тоя мръсен червяк, тоя низък роб,
тоз позор за Бога, туй петно на храма
Дякона погуби чрез черна измама!
Тоз човек безстиден със ниско чело,
пратен на земята не се знай защо,
тоз издайник грозен и Божи служител,
който тая титла без срам бе похитил,
на кого устата, пълна с яд и злост,
изреваха подло: „Фанете тогоз!“
На кого ръката не благословия,
а издайство свърши, и гръм не строши я,
и чието име аз не ще спомена
от страх мойта песен да не оскверня,
и кого родила една майка луда,
който равен в адът има само Юда,
фърли в плач и жалост цял народ тогаз!
И тоз човек йоще живей между нас!

Колкото и да си щастлив, нещо трепва в теб при тези думи. А как не се сещам за една толкова универсално-действаща строфа, в която се говори за победа, щастие, радост… Да, има такива, много, но за да ги изживееш трябва да си подходящо настроен в момента.

Дали само аз съм устроен така? Или ние, българите, известни с песимизма си, сме възпитани да възприемаме отрицателното? Или такава е природата всички хора – мрачното да ни достига по-лесно от светлото? Защо понякога е толкова трудно да поддържам оптимизма си, а масата песимисти си живеят в самосъжаление без да се напрягат много?

„Аз съм щастлив и доволен. Аз съм влюбен, живота ми е песен, работата ми е страхотна, имам много добри приятели, нямам значими здравословни, финансови, семейни или каквито и да са проблеми „
Как мога да напиша такова нещо така, че който го прочете да се зарадва, да се усмихне и да ми съчувства?
„Вчера подкарах dataguard в доста интересна конфигурация. Уикенда инсталирах успешно един RAC и му пуснах AWE, а само преди месец подкарах и четиринодов клъстер”
Искам да споделя радостите и успехите си със света и да го направя малко по-светло кътче. Но като ги напиша и звуча като някакъв самохвалко. Хайде, аз не претендирам за словесни способности близки до Иван Вазов. Но моля ви, покажете ми един текст на радост, толкова универсален, че да се разбира от всеки и по всяко време.

Само си приказвам, де…

 Posted by at 10:33

Семинар на BGOUG

 Без категория  Коментарите са изключени за Семинар на BGOUG
мар. 132007
 

Пролетният семинар на БГПО ще се проведе в хотел „Санкт Петербург“, гр. Пловдив в периода 20–22.04.2007 г. Ако някой не знае, БГПО е Българска Група на Портребителите на Оракъл. Нещо като BGOUG, обаче на български.

Срещите на BGOUG винаги са интересни. Там се чувстам страхотно, чувствам се сред „свои хора“. Въпреки че познавам много малка част от присъстващите. Прекалено малка. Ужасно малка част от участниците.

От първия път, когато присъствах на семинар на BGOUG (ноември 2004), не съм изтървал нито един. Нещо повече – нито една лекция не съм пропуснал. И не, няма да кажа, че всичките са ми били интересни или са били хубави. Но семинарите се градят около тези лекции, а семинарите са нещо много приятно. А и наистина повечето лекции са добри. Почти всички. Дори тези, които не са добре подготвени или изнесени – все пак някой се е постарал. Защото и моята първа лекция беше „насила“ и не прозвуча добре. (От тогава не съм позволявал да ме принуждават да се излагам така).

В семинарите на BGOUG има много голямо усещане за… за общност. За едно голямо и значително общество. Тези семинари са много повече от „слушане на интересни приказки“. Там можеш да се запознаеш с ужасно много хора и да си говорите на тема Oracle и всички ще те разбират, и всички ще ти отговарят. Това го няма никъде.

Е, има и хора, които ходя там за да се повеселят за сметка на фирмата. Има хора, които не стъпват на лекциите. Има и лекции с открито рекалмна насоченост (рядко, де…). Но тези подробности не могат да засенчат добрата идея и добрата организация.

Благодарен съм на организаторите – оснавно Милена, с нея контактувам най-много. Но и всички други. SPI – всява спокойствие и непоклатима увереност. Калинка Калоянова – ако всички хора, занимаващи се с обучение на студенти са толкова ангажирани, няма да има глад за специалисти… И другите, от коит нямам преки впечатления, но съм сигурен, че правят много. Цялата тази ужасно сложна организация, намиране на място, събиране на лектори, участници, всичко… Това е едно страшно голямо предизвикателство, което поемат, доброволно, два пъти годишно. И те го правят, без да получават нещо материално. Отделят от (сигурен съм) ценното си време за да подготвят всичко така, че като отида аз, ти, всички, да ни е хубаво, да ни е готово всичко и да си изкараме супер.

Така че… заповядайте. Ще бъде хубаво, като всеки път. Сигурен съм 🙂

Регистрация за участие можетъе да направите ТУК
Краен срок за регистрация 31.03.2007 г.

 Posted by at 11:32
мар. 122007
 

Понякога губя уважението на разни хора, с които говоря. Ядосвам ги като изказвам тезата, че сами сме си виновни. „Да, ама Софиянски заграбил това и това…” „Брата на Милен Велчев има хотел там и там…” „Стоичков се вози в такъв и такъв джип…”.

Абе какъв сме народ, всеки гледа в паницата на другия! И чул-недочул мърмори, че другия има повече. Ами ако искаш да имаш и ти повече, налягай си задника и направи така, че и ти да имаш! А другия ако е получил „повече” по кофти начин – има си прокурори да „му се скарат”. Ако не – халал да му е!

Изпадам в крайности. Но много вярвам в „Не е луд който яде баницата – луд е който му я дава”.
„Някой си построил хотел” – ами могъл – построил!
„Някой си купил мерцедес” – ами могъл – купил си!
„Да, ама и аз искам мерцедес…” Ами направи така, че да имаш! Питаш ли го другия колко се е гърчил докато си го купи? Колко жертви е направил, колко нощи не е спал, колко страхове е брал, колко рискове е поел и как се е потил докато си го купи? Не, ти виждаш, че той кара Мерцедес. Ес класа. И казваш „тоя тук, измамник, далавераджия, такъв-онакъв…”

Абе какво е това нашето всенародно възпитание! Изтъкани от завист и мрънкачество… Не че няма измамници в мерцедеси. Ооо, много са. Ама не мога да разбера какво ще постигна аз, ако стоя и мрънкам кой какво има. Вместо да се мъча аз да изкарам повече, така че и аз да имам. Какво ще постигна като ден след ден се ядосвам и депресирам от това кой колко повече има от мен, вместо да се радвам на малкото (или многото, ако съм упорит и успея), което изкарам.

Това май е продължение на любимата ми тема за оптимизма. Вместо да гледаш колко повече има някой от теб, виж колко повече имаш ти от… от вчерашното „ти”. И направи така, че утре да имаш още повече. А другия че имал повече – ами добре, постави си го за цел. Да имаш колкото другия. И се радвай на всеки ден, в който успееш да се доближиш. На всеки ден, в който успееш да се дръпнеш напред.

Вместо да се опитваш да дърпаш другия назад.

Само това е пътя да имаме всички по повече. Ако всеки един, сам за себе си, се старае да напредва. По възможност – честно.

 Posted by at 9:35

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

 Без категория  Коментарите са изключени за RAC Basics 3 – DLM, PCM, Ping, Cache Fusion
мар. 092007
 

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

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

Когато БД стане многопотребителска, много процеси трябва да си споделят достъпа до данните и всеки да вижда и променя точно каквото трябва. Недопустимо е един атомарен ресурс (примерно ред от таблица) да бъде променян от два процеса едновременно. Това увеличава значително сложността на транзакционните механизми и поставя изискване от заключвания, които да сериализират достъпа. Някои СУБД и сега не се справят успешно с това и предоставят „груб” 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 ще има в следващата част от поредциата

 Posted by at 14:22