Зимата ни изненада

 Общи  Коментарите са изключени за Зимата ни изненада
Дек. 212009
 

Не става дума за общината или пътната агенция. А за нас, шофьорите.

В прословутия задръстен петък, когато цяла София орева света колко непочистени са улиците, аз пътувах малко под 2 часа до офиса. Честно казано, винаги при първия голям снеговалеж става екшън. Докато зацепи тромавата машина, отговорна за снегопочистването – и то вече наваляло. После за няколко часа все пак се справят и до края на деня основните улици са много добре почтистени. Както беше и тази година.

Не така стои въпросът със стотиците хиляди шофьори, които си мислят, че зимата може да се кара с летни гуми. Примерът е точно то петък. По малкото баирче от Малинов към Цариградско беше брутално задръстване, както на всяко друго място. Колите бяха в 2 колони и придвижването ставаше на етапи – тръгваш, пълзиш, спираш, чакаш и пак тръгваш. Ако можеш.

Точно пред мен имаше един червен Сеат, който след спирането не можа да потегли. Сега, вярно, пътят не беше изблизан до асфалт, ама няма как да разчиташ, че винаги ще е. Те за това има зимни и летни гуми. Та спира сеата по средата на баирчето, и като потегля колоната пред него, той започва да върти гуми. Напред не мръдва, ама яко се унесе на дясно към „другата“ лента (в която имаше автобус 76). Като видях какво става, пуснах едни аварийки и слязох да предложа да го бутна (няма как да върна назад – колоната не мърда назад).

Пича, обаче, съвсем рационално отказа моята помощ. Защото вече беше почти опрял в автобуса. Изчака дясната колона да мине достатъчно, че да се източи автобуса и при две свободни „ленти“ успя да потегли на зиг-заг. Качи баирчето с постоянно въртене на гуми и обиколки от едната лента в другата.

Аз, естествено, се притесних и за себе си. Все пак на гладък лед и зимните гуми не помагат. Пътят не изглеждаше точно като гладък лед, ама като гледах мъките на сеата… и нали съм спрял на същото място…

Да, ама не. Рендето си потегли съвсем безгрижно. Т.е. пътя не е бил съвсем на стъкло, просто заснежен. И се чудя с кой ли акъл е тръгнал тоя. И пак е късметлия, че закъса на горе. Защото ако гумите те предадат по надолнище, го отнасяш и ти, и невинните пред теб.

* * *

В събота улиците бяха перфектно почистени. Стигнах до работа за 35 минути. Както и днес. Но то нямаше и голямо движение. Явно тия с „цървулите“ бяха разбрали по трудния начин, че така няма да стане. Пак. Всяка година при първия сняг улиците се задръстват от тях. Хем то и през прозореца се вижда, че вече не е лято. Ама те да опитат…

* * *

Миналата зима. Имаше доста навалял сняг. Прецених, че ще видя зор да изляза от паркинга пред блока. Извадих от багажника една лопата, която си нося по цяла зима за такива случаи (да е жив и здрав Весо, че ми я подари) и си разринах. Като ме видя една съседка помоли да и дам лопатата, да си почисти и тя пред нейната кола. Аз съвсем кавалерски отидох лично да и разрина. Завързахме лаф и подхвърлих, че ако е с добри гуми няма да има проблем – стигне ли до пътя. Тя каза, че гумите и са много зле.

Зачудих се къде ли е тръгнала в тоя сняг, щом няма добри гуми. След като и разринах, на бегом се върнах до моята кола и се изнизах преди да е запушила пътя.

* * *

Срещу офиса има гумаджийница. Днес има голяма опашка, както беше и в петък и събота. Някои коли не могат да се качат на тротоара да си изчакат реда – то с галошите трудно става… Е сега ли е момента да си сменяш гумите? Сигурно още по-големи са опашките пред тенекеджийниците 🙁

 Posted by at 15:22
Дек. 212009
 

(към част 4)

С предишната част от поредицата показах един малко използван и доста мощен вариант за защита. В повечет случаи той е „прекалено“ ограничаващ (харесвам термина scalability inhibitor). Но може да се окаже полезен в случаи, когато едни данни се модифицират от токова много и различни места кода, че никой не ги знае всичките (спагети).

Обратно, когато се знае точно кои парчета от кода ще достъпват данните, се дефинират критични секции. За целта може да използва много интелигентно заключване с помощта на пакета dbms_lock. Този пакет предоставя възможност да се използват познатите ни вградени в Оracle механизми за заключване, за да управляваме достъпа до „наши“ си ресурси. Основно предимство пред hand-made заключваниците е, че механизма е доказан, тестван, железен и познат. За да може потребителя да използва този механизъм, трябва да има права за изпълнение на dbms_lock.

Ето малко примерен код:

create or replace procedure Process_New_Data is
  lck_handle number;
  lck_result binary_integer;
begin
  -- preventing multiple sessions run the same code
  DBMS_LOCK.ALLOCATE_UNIQUE(lockname => 'New_data_processing', lockhandle => lck_handle);
  lck_result := DBMS_LOCK.REQUEST(lockhandle => lck_handle, lockmode => dbms_lock.X_MODE, timeout => 0,
                                  release_on_commit => false);
  /* possible results:
    0 - Success; 1 - Timeout; 2 - Deadlock; 3 - Parameter error; 
    4 - Already own lock specified by id or lockhandle; 5 - Illegal lock handle
  */
  if lck_result != 0 then
    RAISE_APPLICATION_ERROR(-20115, 'Cannot allocate lock New_data_processing: ' || lck_result);
  end if;

  -- do wathever we want
  loop 
    insert . . .;
    delete . . .;
    commit; -- we can do many transactions, the lock is defined with release_on_commit => false
  end loop;
  update . . .;
  commit;

  -- release the lock
  lck_result := DBMS_LOCK.release(lockhandle => lck_handle);

EXCEPTION
  WHEN OTHERS THEN
    -- we should always release the lock!!!
    lck_result := DBMS_LOCK.release(lockhandle => lck_handle);
    -- do whatever error handling we need
    rollback;
    insert into Processing_log
      (time, module, action, error_msg, extra_data, status)
    values
      (sysdate, 'Process_New_Data', null,
       DBMS_UTILITY.FORMAT_ERROR_STACK() || chr(13) ||
       DBMS_UTILITY.FORMAT_ERROR_BACKTRACE(),
       null, 'Error');
    commit;
    raise;
end;

Основните моменти тук са:

– В началото си дефинираме „ресурс“, който ще заключваме, с помощта на DBMS_LOCK.ALLOCATE_UNIQUE

– После правим опит за заключване на този ресурс с DBMS_LOCK.REQUEST. Тук могат да се използват различни нива на закючване (Shared, Exclusive, SubShared, SubExclusive, Shared SubExclusive).
Може да изчакаме известно време (timeout) – това е много полезно, ако се очаква ресурса да бъде заключван за кратко, след което ние можем да успеем да го получим.
Има и още един много приятен параметър: release_on_commit. С него управляваме дали заключването да се освобождава автоматично при приключване на транзакцията (както правят всички нормални заключваници).
Една важна подробност е, че при неуспех процедурата не връща exception. За това трябва да се обработи резултата, който връща.

– След това може да се прави всичко според бизнес изискванията. Ако заключването е направено с release_on_commit => false, спокойно може да се реализира и код с много транзакции (като в част 1).

– На края ресурса се отключва с DBMS_LOCK.RELEASE. Тук отново при неуспех няма exception, а различен return value.

– Важно е да се подсигури „отключването“ на ресурса с exception handler. Ако по някаква причина не го направим и процедурата „гръмне“ по средата, той ще си остане заключен до края на сесията.

 Posted by at 13:27

Не сме сами, част 4

 Общи  Коментарите са изключени за Не сме сами, част 4
Дек. 172009
 

(към част 3)

Основно правило при многопотребителската работа е да си заключваш ресурсите, с които работиш. Едно здраво заключване може да спести много главоболия. За съжаление за да направиш добро заключване, трябва 1) да си осъзнал, че ти трябва, и 2) да знаеш как да го направиш 🙂

Повечето хора се сещат за select ... for update. Обаче има и други заключваници, които могат да помогнат на съвестния db developer. Единият вариант е Lock table. Ще използвам примера от част 2:

create or replace procedure Process_New_Data is
  -- example code - not scalable!!!
begin
  -- lock the log table, so none will be able to add/remove batches
  lock table batch_log in exclusive mode;
  -- process the loaded batches
  insert /*+append*/
  into prod_table
    select -- do some processing
           batch_id, get_something(column1, column2), calculate_something(column3, column4),
           RANK() over(PARTITION BY column5, column6 order by column7) rn, 
           column8, column9, ...
      from loader_table
     where batch_id in (select batch_id
                          from batch_log
                         where processed = 0);

  -- delete the rows from loader table
  delete from loader_table
   where batch_id in (select batch_id
                        from batch_log
                       where processed = 0);

  -- mark the batches as processed
  update batch_log
     set processed = 1
   where processed = 0;

  commit;
end;

В случая още в началото на процедурата заключваме таблицата batch_log. Това означава, че никой няма да може да добавя, променя или премахва редове от нея. :
– ако има сесия, която вкарва нови данни, при опит да направи insert – ще чака.
– ако има друга сесия, която изпълнява нашата процедура за обработка/преместване на данни – ще гръмне или ще чака, в зависимост от това дали ще дадем wait на заключването. Това е и една от причините този lock да се прави в самото начало, преди да сме свършили някаква друга работа.

Самото заключване се „отключва“ автоматично в с първия commit или rollback. За това точно този подход е неприложим в ситуации като описаната в част 1.

По-лошото е, че този подход е адски не-скалируем. Това е brute force на защитата. Докато не приключим с всичката работа, никой няма да може да работи по тази таблица (освен да select-ва). С други думи, заменили сме един проблем с друг. И сега проблема ще се прояви при натоварване с конкурентни сесии. Може да се каже, че сме по-добре: проблемът ще е ясен, няма да има случайни загуби или дублиране. Но си е проблем.

Интересна дилема: колкото повече (и по-рестриктивни) заключваници използваме, толкова по-зле понася товар едно приложение. Но ако не ги използваме, добрата саклируемост води до грешни данни. Някой да си е помислил, че има просто решение? 🙂

(към част 5)

 Posted by at 11:54
Дек. 172009
 

Тази сутрин една БД ме посрещна с 5 сесии, които висят от няколко часа върху 'cursor: pin S wait on X'. Бърз поглед из нета ми показа, че има твърде много буболечки, свързани с тия мутекси.

Но на Коледа стават чудеса. Оказа се, че при мен проблема е много по-прозаичен. Трябваше само да намеря кой, по дяволите, е отговорен заключването. Оказа се, че всяка от 5-те сесии чака различна друга сесия. Коя по-точно се намира така:

SELECT inst_id, sid blocked_sid, p2raw, 
       to_number(substr(to_char(rawtohex(p2raw)), 1, 8), 'XXXXXXXX') blocking_sid
  FROM gv$session
 WHERE event = 'cursor: pin S wait on X'
 order by 1, 2;

Всички виновници се оказаха заспали долу-горе по едно време, все поради прекъсване по средата на distributed query. Причините за това хлъцване са ми ясни. Просто за пръв път виждам това да доведе до спор за мутекси…

Избих заспалите сесии и отидох да си направя чай.

А на вън вече не вали сняг.

 Posted by at 9:22
Дек. 152009
 

В събота вечерта бях на коледно парти на софийската секция на съюза на зъболекарите. Всъщност, колкото и ужасно стресиращо да звучи, това да си в едно помещение със 100-200 зъболекари хич не е страшно. Ако мога да използвам този израз: и те са хора, и те душа носят 😉

Огромни поздравления: цялата вечер (или поне до полунощ, когато си тръгнах), не пуснаха никаква чалга. Браво!

Ужасното е друго. Мероприятието беше в един от ресторантите на парк-хотел „Москва“. Нали се сещате – хотела е кръстен на руската столица Москва. А миналата седмица доста се шуми за Русия и по-точно за град Перм. Там, предната събота вечер, в пожар в дискотека загинаха над 140 души. Причината за огромния брой жертви: недостъпни аварийни изходи.

Изглежда, обаче, в нашият си парк-хотел Москва пожарната безопасност не е първа грижа. Това, което ме наведе на тази мисъл, е следното:

На снимката вижда е авариен изход (точно до „дансинга“ в ресторанта) – добре преграден с маси и столове. Така де, това е най-подходящото място да се захвърлят излишните мебели. Да не дава господ да се наложи използването му.

Някой има ли идея дали при забелязване на такава нередност мога да се обърна към някоя институция? Към някой, който ще де вдигне в събота вечер да установи нарушението, да им тресне един як акт, че да се замислят следващият път?

 Posted by at 12:38
Дек. 142009
 

Във връзка с един проект имахме на гости в МТел – консултант от Полша. Той стоя десетина дена и си вършеше кротко работата, без да му се месим много много. Интересното е, че нито веднъж не можах да го примамя да дойде с нас на обяд. Казваше, че предпочита да обядва по неговото часово време (+1 час). Но аз предполагам, че просто предпочиташе да прилапва един сандвич набързо и да си върши работата.

Така се случи в петък, че изведнъж нещата станаха малко на зор. Наложи се да бачкам с него активно и по случая и аз пропуснах да отида да манджам заедно с колегите. Към 13:30, вече доволно гладни, слязохме до сандвичарницата (точно срещу входа на сградата, през улицата). Пред нас имаше още двама „гладни“, които също се оказаха чуждоземци (май от Израел).

Сега, аз не знам как върви пазара на труда при хората, които работят в такива места. Но предполагам, че в обявите за работа няма залегнало „познаване на английски език“ – поне не и за капанче забутано в този огрухан софийски квартал. Но жената вътре наистина се стараеше да разбере какво искат хората. Лошото е, че в това капанче човек може да си поръча нещо като мини-пица с продукти по избор, и точно това правеха евреите:

I want two pizzas… – каза клиента
Оу кей, ту пици. С какво да бъдат? – беше логичния отговор на продавачката
With vegetables…
???
След 2-3 опита клиента се обърна към опашката и попита как е vegetables на български. Аз му подсказах достатъчно силно, че да ме чуе и продавачката. Все пак той предпочете да предаде лично:
Zelenchutsi – каза почти без акцент. Или е казал זילינשוּצי
Аха, зеленчуци. Друго? – въпреки затрудненията, продавачката имаше намерение да изпълни цялата поръчка
Olives
??? – последва логичното чудене на дамата зад прозорчето
Maslini – уточни клиента след моето подсказване. И така поръчката се задейства.

След това беше ред на моя поляк. Честно казано, имах намерение аз да се заема с поръчката. Но той започна смело, имайки 10 дена опит в поръчването на сандвичи на това място:
I want a sandwitch with ham.
Оу кей, сандвич със шунка – и каката се зае да пресова тоста – Салати?
Tomatos
Оу кей, домати
Something red
Оу кей – „WTF? помислих си аз“. Продавачката явно знаеше за какво става дума.
And this – завърши поляка, сочейки руската салата, която имаше късмета да стои точно до отвореното прозорче.

Е, разбраха се без моята намеса. Всъщност аз бях единственият, който не знаеше какво е something red. За това с голям интерес проследих как каката извади тоста от пресата, сложи домати, руска салата и… лютеница 🙂

По-късно моя човек ми каза, че много му харесало това червеното нещо (лютеницата) и си го поръчвал всеки път. Само не ми стана ясно как са се разбрали първия път. Може би пак с посочване.

 Posted by at 9:49
Дек. 102009
 

Писна ми „сглобените“ компютри да са в някакви хипер големи кутии. Защо няма „жълти“ кутии с размерите ми служебното ми HP: 350 х 100 х 350? За какъв блян са ми 5 дупки за 5.25“ устройства – да не съм шибана фабрика за пиратски дискове! Ще си сложа само едно просто DVD! Не държа да има място и за 3-4 харда – c’mon, пиратските ftp сървъри вече не са на мода!

До сега най-малкото, което съм намерил на българския пазар, е Hedy M0205, обаче и тя е 412 x 175 x 380. Някой виждал ли е да се продава нещо по-малко?

 Posted by at 9:48
Дек. 092009
 

Преди две седмици датски журналисти публикуваха информация, според която експерти от Световната здравна организация са вземали добри пари от големи фармацевтични компании, спечелили за кратко време огромни суми от продажба на лекарства срещу свинския грип.

И от тогава този вирус сякаш изчезна. За него се шуми не по-вече от колкото за обикновения – т.е. почти нищо не излиза извън кръга на медицинските специалисти, които са професионално заинтересовани. Вече никой не брои ежедневно заразените. Новините не започват с поредната сводка за разпространението му. Сякаш наистина не е нещо хипер-супер-мега-гига-турбо опасно. Не и по-опасно от „простия“ грип, примерно. Или от хепатита, туберколозата или всяко друго заболяване, която може да събори на легло всеки един или да убие човек с отслабена имунна система.

Май наистина пандемията ще се окаже журналистическа раздувка, умело подклаждана от „заинтересовани“ експерти, а?

 Posted by at 13:49