Имаме следната задача: Table1 съдържа имена на клиентите на най-голямата квартална бакалия в Мюнхен, а Table2 съдържа феновете на Байерн Мюнхен. Пита се колко от феновете на Байерн пазаруват в бакалията.
Да предположим, че данните са First Name (FNAME), Last Name (LNAME), CITY, COUNTRY.

Най-елементарното решение е следното:

select *
  from table2 t2
 where exists (select 1
          from table1 t1
         where t1.fname = t2.fname
           and t1.lname = t2.lname
           and t1.city = t2.city
           and t1.country = t2.country)

Това ще ни даде резултат ако всички имена са написани по паспорт. Но както всички знаем, данните не винаги са така чисти. Примерно господин Schmitt от феновете може да е записан в бакалията като Schmidt; госпожица Pavlovich може да е Pavlovic; John Smith не съвпада с John Smit и т.н. Абе трябва нещо по-добро.

Има една функция, което се опитва да оцени звуковото съответствие (работи само за латиница!) и това е soundex. Начина и на действие е относително прост и е описан тук. Да видим какво става с нея:

select *
  from table2 t2
 where exists (select 1
          from table1 t1
         where soundex(t1.fname) = soundex(t2.fname)
           and soundex(t1.lname) = soundex(t2.lname)
           and t1.city = t2.city
           and t1.country = t2.country)

(за простота, или от простотия, приемам че държавите и градовете са написани еднакво. Иначе може да се приложи същата трансформация)

Опа… излязоха твърде много резултати. За мен няма нищо общо между Marko Mjagkov и Marica Moisejevs, но на soundex му звучат еднакво – M620 M221. Да опитаме нещо друго

Има едни красив, относително нов пакет, известен като utl_match. В този пакет има реализирани 2 алгоритъма, разработени за борба с точно такъв проблем – сравняване на имена. Единият е измислен от руския математик Владимир Левенщайн през далечната 1965 (функцията EDIT_DISTANCE), а другия комай е с американски произход, резултат от дългогодишния труд на господата Matthew Jaro и William Winkler, публикуван през 1990. Колкото и да бях добър с математиката като ученик и студент, сега съм забравил всичко и математическия апарат ми е твърде сложен; но пък мога да използвам функциите наготово и без да му мисля много, да проверя колко са „близки“ имената:

select *
  from table2 t2
 where exists (select 1
          from table1 t1
         where utl_match.jaro_winkler(t1.fname, t2.fname) > 0.9
           and utl_match.jaro_winkler(t1.lname, t2.lname) > 0.9
           and t1.city = t2.city
           and t1.country = t2.country)

Тук, обаче, достигам до друг проблем – няма ефективен начин а ускоря заявката. Ако бакалията има 10 000 клиенти от Мюнхен, а Байерн има 500 000 фена в родния си град, то имаме реален шанс да изпълним функцията utl_match.jaro_winkler над 5 000 000 000 пъти. При това ще сравнява, примерно, Адолф с Грета – нищо общо. Никакви индекси или оптимизации не помагат, просто груба сила. Това си отнема доста (процесорно) време.

И така, за нуждите на моето изследване аз достигнах до следното комбинирано решение

select *
  from table2 t2
 where exists (select 1
          from table1 t1
         where soundex(t1.fname) = soundex(t2.fname)
           and soundex(t1.lname) = soundex(t2.lname)
           and utl_match.jaro_winkler(t1.fname, t2.fname) > 0.9
           and utl_match.jaro_winkler(t1.lname, t2.lname) > 0.9
           and t1.city = t2.city
           and t1.country = t2.country)

Тук със soundex сравнението орязвам значително проверките, макар и да имаме доста false positives. За по-извратени случаи може да направим функционален индекс по soundex.
После с utl_match.jaro_winkler намирам най-вероятните съвпадения от вече намаления набор. Вярвате или не, това върви доста добре – при таблици с 20К и 2M реда (всичките от един град), минава за десетки секунди и дава доста смислени резултати. Разбира се, доста от съвпаденията може да са случайни – не само един мюнхенец се казва Ханс Шмит. Но все пак е някакво начало.

P.S. По време на research-а попаднахме на многообещаващия Петьо. Отказахме се от него, защото иска extproc, а ние избягваме този механизъм защото може да отвори дупка в сигурността. Иначе изглежда прекрасно

 

Презентацията ми „The adventure of upgrading to 11.2″ от есенния семинар на БГПО в Хисар – тук

Отново изразявам моите огромни благодарности и възхищение на Милена, СПИ и другите организатори, които инвестират много от личното си време и енергия за да направят тези семинари. Страхотна работа, отново!

 

Това е една друга интересна мотика при upgrade от 10g на 11g. По време на автоматизираните тестове забелязахме, че audit trail таблицата се раздува с бясна скорост и една забележима част от IO операциите са именно писане в SYS.AUD$.

Открихме следната нота в Metalink:
Huge/Large/Excessive Number Of Audit Records Are Being Generated In The Database [ID 1171314.1]

1.) Starting with Oracle 11g the BY SESSION clause is obsolete. This is documented in the Database Security Guide :

“ The BY SESSION clause of the AUDIT statement now writes one audit record for every audited event. In previous releases, BY SESSION wrote one audit record for all SQL statements or operations of the same type that were executed on the same schema objects in the same user session. Now, both BY SESSION and BY ACCESS write one audit record for each audit operation. In addition, there are separate audit records for LOGON and LOGOFF events. “

Because of the above change it is expected that the number of the audit records/files will grow considerably.

Засилвайки се към документацията открих следното:
Oracle® Database SQL Language Reference 11g Release 1 (11.1)

BY SESSION

In earlier releases, BY SESSION caused the database to write a single record for all SQL statements or operations of the same type executed on the same schema objects in the same session. Beginning with this release of Oracle Database, both BY SESSION and BY ACCESS cause Oracle Database to write one audit record for each audited statement and operation. BY SESSION continues to populate different values to the audit trail compared with BY ACCESS. If you specify neither clause, then BY SESSION is the default.

На практика същото пише и в Oracle® Database SQL Language Reference 11g Release 2 (11.2)

Още по-неясно е написаното в Oracle® Database Security Guide 11g Release 2 (11.2)

Benefits of Using the BY ACCESS Clause in the AUDIT Statement

By default, Oracle Database writes a new audit record for every audited event, using the BY ACCESS clause functionality. To use this functionality, either include BY ACCESS in the AUDIT statement, or if you want, you can omit it because it is the default. (As of Oracle Database 11g Release 2 (11.2.0.2), the BY ACCESS clause is the default setting.)

Oracle recommends that you audit BY ACCESS and not BY SESSION in your AUDIT statements. The benefits of using the BY ACCESS clause in the AUDIT statement are as follows:

Честно ви казвам, тия неща ми звучат като „Ъъъъ… бе нещо се повреди тоя BY SESSION, ама успяхме да го позакрепим, макар че вече работи почти като BY ACCESS“

Трябваше да предефинираме audit политиката си преди upgrade-a. За щастие повечето noaudit операции стават online. Единствено noaudit execute прави гадни заключвания и трябваше да го правим по време на downtime.

Ето и едно полезно query по въпроса:

select 'noaudit select on ' || owner || '.' || object_name || ' WHENEVER SUCCESSFUL;'
  from DBA_OBJ_AUDIT_OPTS
 where sel like 'S/%'
   and owner in ('...application schemas...')
   and object_name not in ('...exclusions...')
union all
select 'noaudit execute on ' || owner || '.' || object_name || ' WHENEVER SUCCESSFUL;'
  from DBA_OBJ_AUDIT_OPTS
 where exe like 'S/%'
   and owner in ('...application schemas...')
   and object_name not in ('...exclusions...')
union all
select 'noaudit update on ' || owner || '.' || object_name || ' WHENEVER SUCCESSFUL;'
  from DBA_OBJ_AUDIT_OPTS
 where upd like 'S/%'
   and owner in ('...application schemas...')
   and object_name not in ('...exclusions...')
union all
select 'noaudit insert on ' || owner || '.' || object_name || ' WHENEVER SUCCESSFUL;'
  from DBA_OBJ_AUDIT_OPTS
 where ins like 'S/%'
   and owner in ('...application schemas...')
   and object_name not in ('...exclusions...')
union all
select 'noaudit delete on ' || owner || '.' || object_name || ' WHENEVER SUCCESSFUL;'
  from DBA_OBJ_AUDIT_OPTS
 where del like 'S/%'
   and owner in ('...application schemas...')
   and object_name not in ('...exclusions...')

И още нещо много важно: не забравяйте да си прегледате какво пише в ALL_DEF_AUDIT_OPTS преди upgrade. Иначе catupgrd ще ви създаде хиляда хиляди обекта с кофти auditing.

 

Това не го очаквах. Обикновено с новите версии на Oracle нещата скалират по-добре; има по-малко заключваници от предишните версии. Това, което ще опиша, е ново за 11g

Някой би казал, че това е некадърен дизайн на приложението. Всеки знае, че foreign key колоните трябва да се индексират. Обаче в 10g това водеше до по-бавно изтриване от parent таблицата, или по-бавен update на primary key в нея (докато се сканира child таблицата за съответни записи). А сега имаме изцяло ново поведение – заключване, което може да продължи произволно дълго време. Един прост INSERT в parent таблицата може да блокира всички други сесии, които се опитват да направят UPDATE или DELETE (пак на parent таблицата). Тук изобщо не говорим за промяна в child таблицата – достатъчно е да я има, ако ще и празна. И за да ни е по-весело, ние настъпахме тая мотика с child таблица от 724 реда, на която full scan-а в 10g е минавал светкавично и не сме усетили никакъв проблем.

* * *

Ето и подробностите. Note 1343365.1 казва следното

There is change in lock modes behavior introduced intentionally by fix 5909305 in 11.1 onward.

Change has been made to DML (TM) lock modes for foreign key constraints (Doc ID 5909305.8).

The change in behavior mentioned in note 5909305.8 , introduces higher level of lock on parent table while running DML against Child table. ( SX vs SS )

There are cases unrelated to this bug which lack of indexes on foreign key columns increase the time locks take place. This reflect as wait on TM-enq.

Звучи безобидно. Поведението на SS и SX е почти еднакво. Има 2 разлики – SX не е съвместим с други S и SSX (Share и Share Sub-eXclusive) заключвания. Но тия двете не се срещат в ежедневната работа с DML заявки. Почти.

Тук се включва неиндексирания foreign key. Това е единствения DML за който знам, който прави S заключване на цялата child таблица. И така, със следните прости стъпки аз успявам да се заключа всеки път на 11.2.0.2:

1. Подготвям си таблици и данни

drop table t2 purge;
drop table t1 purge;

create table t1 (pk number primary key);

create table t2 (pk number primary key, fk number references t1(pk));

insert into t1 values (1);
insert into t1 values (2);
insert into t1 values (3);
insert into t1 values (4);

insert into t2 values (11, 1);
insert into t2 values (21, 2);
insert into t2 values (22, 2);
insert into t2 values (31, 3);
insert into t2 values (32, 3);
insert into t2 values (33, 3);

commit;

2. Залагам капана от сесия 1

insert into t1 values (5);

Кратък поглед във v$lock показва, че нашата сесия 1 държи 3 заключваници (всъщност малко повече в 11g, но трите са най-интересни)
- mode 6 (eXclusive) TX lock върху новия ред
- mode 3 (Sub eXclusive) TM lock върху таблицата t1 (демек parent таблицата). обърнете внимание, че това е заключване на таблицата, а не на някой ред в нея
- mode 2 (Sub Share) при 10g или Mode 3 (Sub eXclusive) при 11g, TM lock на таблица t2 (това е child таблицата). Отново това не е свързано с никакви редове в нея – може да има, може и да няма засегнати редове. Такива заключвания има за всички таблици, които имат foreign key constraint, сочещ към нашия parent.

3. Опитваме да променим или изтрием произволен (друг) ред от parent таблицата от сесия 2:

delete from t1 where pk=4;

или

 update t1 set pk=2 where pk=2;

В 10g това минава безгрижно. Обаче в 11g и двете зависват, опитвайки се да получат Mode 4 (Share) lock на child таблицата – защото foreign key колоната не е индексирана.

Как да си намерим неиндексираната таблица:
FВсъщност аз забелязвам сесиите, чакащи за TM locks в Grid Control. Там излизат едни червени неща, лесно се виждат. Може да ги видим и във V$SESSION:

 SQL> select sid, final_blocking_session
  2    from v$session
  3   where event = 'enq: TM - contention';

       SID FINAL_BLOCKING_SESSION
---------- ----------------------
       132                    332

За да намерим проблемния ресурс (с други думи – таблицата без индекс), пускаме това:

 SQL> select SID, type, id1, lmode, request, block
  2    from v$lock
  3   where sid in (132, 332)
  4     and type = 'TM';

       SID TYPE        ID1      LMODE    REQUEST      BLOCK
---------- ---- ---------- ---------- ---------- ----------
       132 TM       950744          3          0          0
       132 TM       950746          0          4          0
       332 TM       950744          3          0          0
       332 TM       950746          3          0          1

На ред номер 4 пише BLOCK=1, т.е. това заключване *блокира* някой друг. На ред номер 2 виждаме REQUEST=4 и LMODE=0 – това показва, че сесията има нужда от mode 4 lock, обаче не може да се уреди. Колоната ID1 в случая е object ID (за TM locks):

 SQL> select owner, object_name, object_type
  2    from dba_objects
  3   where object_id = 950746;

OWNER      OBJECT_NAM OBJECT_TYPE
---------- ---------- -------------------
YAVOR      T2         TABLE

Решението е лесно, след като сме открили проблема. Просто създаваме индекс на foreign key колоната от child таблицата

 create index t2_fk on t2(fk);

След създаването на индекс, промяната върху parent таблицата вече не прави S заключване на child. Вместо това се прави SX заключване, което е съвсем съвместимо с другия SX.

Това поведение е трудно за обяснение на develpers. Честно казано, дори и аз не мога да си обясня как индекса премахва нуждата от S lock и го намаля на SX. Ние не засягаме никакви редове в child таблицата. Ама… така са го направили.

 

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

 

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

После освободих стаята – така или иначе трябва да се изнесеш до 12 – и оставих куфара на рецепцията. Реших да използвам няколкото свободни часа с фото-разходка из центъра. Имах и още няколко подаръка за купуване, както и една от най-важните задачи: да си намеря ракиена чашка с надпис San Francisco.

И така, няколко снимки от Сан Франциско. Ето една типична баир-улица:

На всички по-големи улици има надписи кога се мият:

Гадната миризма, от която се оплаках в неделя, не се повтори. Но е истина и че всяка нощ валеше.

Ето Union Square:

Забележете горе вдясно панорамните асансьори. Сигурни е много готино да се возиш в тях.

Тези туристически автобуси за разходка тръгват от Union Square. Два са пълни, има опашка за следващия. И като става дума за опашка, вижте какво чакане е да се повозиш на cable car:

Трамвайчето стои разтоварено малко преди обръщалото. Опашката започва вдясно, минава покрай „обръщалото“ и завършва вляво, където е качването. Но всяко трамвайче има ограничен капацитет:

Следваща тема: анти-грипни ваксини. Масова рекламна кампания. Вероятни са спонсорирани от държавата и са далавера, защото всяка по-смислена аптека предлага даже да ви ги бият на място:

Ето и снимка на Yerba Buena gardens. Вляво се вижда един много впечатляващ хотел – Marriott. Доста етажи – поне 30, интересна архитектура и много конферентни зали и стаи – част от сесиите бяха в него.

В средата пък се вижда католическата църква свети Патрик. Ето я и вътре:

Да е жив и здрав никоня, с това високо ISO. Позволих си да направя няколко снимки, защото нямам нужда от светкавица. Ето и детайл от фасадата:

А това е еврейски музей, според надписа:

Много интересна архитектура. И непрактична, ама това май е второстепенно в случая.

И така, обикалям вече над 2 часа, а не намирам сувенирен магазин с ракиени чашки. А аз много държах да си купя, колекционирам ги – имам от 15-20 различни градове из целия свят. Но не щеш ли, изведнъж попадам в някакъв China Town:

Още първото магазинче имаше каквото ми трябва. Продавачите бяха двама латинос, шляпаха на испански. Купих си чашка, а те забелязаха никоня на врата ми и взеха да ме зарибяват с обективи. Цените бяха прекрасни – 600 долара за Nikkor 10-24 (в БГ е 1500 лв). Не посмях да си го взема, де – тази цена беше направо съмнителна. Пък и ако му стане нещо, после ходи търси гаранция.

И така. После се видяхме с Юлиян Дончев за последна раздумка. Той тръгна за летището в към 13:15, за полет в 18 часа. Аз излитах в 21, така че реших да не се поотвам дълго. Обядвах за последно в „американския“ ресторант, прибрах си багажа и тръгнах към BART.

От летището не може да сбъркаш влака – там е само един. Обаче през града минават поне 4-5, така че на „гарата“ попитах кой точно ми трябва. Казаха ми да се кача на тоя, на който пише „San Francisco Airport“. Логично.

Стоварих се на международния терминал към 15:30. Там установих, check in-а на луфтханза работи от 17:45. Куца хава. Ама аз си имам книжка, седалки много – изчаках. Чекирах си багажа към 18:00 часа – същата процедура като тук. Никой не го гледа. Сетих се, че може проверката да е по-нататък. Един приятел са го викнали от гейта за да си отвори чантата, че има нещо съмнително (бутилка Каменица) ама това е в Европа – американците са много по-параноични.

Security check-а на ръчния багаж започва с дълга, но бърза опашка. Сравняват ти старателно снимката с лицето, да не е нещо менте; после задължително се събуваш – обувките минават през скенера за ръчен багаж. Интересното е, че мен не ме пуснаха през машината за преглед „на голо“ – минах само през метален детектор. После си взех обувките и ръчния багаж и газ към duty free-to.

Много исках да занеса бутилка калифорнийско вино. Даже взех две. Обаче като отидох на касата ми казаха, че ще имам проблеми в Мюнхен заради прекачването. И с всичкия си акъл аз се вързах и не взех вино. Пълна глупост – при прекачване (поне в Европа) не се минават никакви проверки.

Ето опит за снимка с относително дълга експозиция, от ръка

Да е жив и здрав VR-а.

Та седя си аз на гейта и си чета. Постепенно се събират все повече хора. И в един момент се чува дългоочаквания повик:
„Passenger Ivanov, please identify yourself at gate G99″
Оф, ще трябва да отварям куфара… Да, ама не – оказа се, че само искали да ми сменят мястото. Няма проблеми, стига да съм до коридора, че ставам често.

Airbus A340-600 май е самолета с най-дългия фюзелаж. Събира до 440 пътника, при това е само на един етаж. Интересното (за мен) решение е, че тоалетните са на „долния етаж“ – така има повече седалки за сметка на по-малко багажно отделение. А се получава и интересно разнообразие – има място, на което може да си повисиш когато ти е тъпо на седалката (има ограничение – до 10 човека – защото там има само толкова кислородни маски). Та на това местенце оставят вафлички, сокчета, вода, кола и т.н.

Ето как boot-ва личната система за забавление:

Windows CE. Интерфейса е подобен на тоя на A380, но резолюцията е по-лоша. Е, все пак и самолета е по-възрастен.

Излетяхме с малко закъснение – може би 10-20 минути. Полета до Мюнхен е по-кратък (около 10 часа и половина), хем Мюнхен е половин час по-далеч от Франкфурт. Забелязах, обаче, че не минахме минахме толкова северно – от Гренландия захапахме само най-южния край, после доста южно от Исландия и влязохме над Шотландия (а не над Норвегия). Освен това през цялото време летяхме с над 950 км/ч, даже често над 1000. Над Холандия прелетяхме с 1070.

Отново имаше 2 ястия – грубо казано два часа след излитане и два часа преди кацане. През повечето време всички спаха, всички прозорци бяха затворени, светлините – угасени. Дори и аз, с всичкия ми страх от летене, поспах 4 часа.

В Мюнхен се приземихме при дъжда, даже и град. Големия самолет мина леко през облаците и се приземи без да изпитвам ужас. Но имах недалновидността а се обадя до България и да разбера, че и в София времето е гадно.

Ето един интересен детайл от терминала в Мюнхен:

Затворени стъклени стаи, пълни с пушачи, които седят вътре като наказани. Всяка от тях – брандирана (и вероятно мощно спонсорирана) от различен производител на тютюневи изделия.

Още нещо интересно:

Абе то на тоя малък размер не се вижда, обаче на тази снимка има 6 (шест!) самолета, които кацат на 2 писти. Интервала между кацанията е под минута. Е това е казва трафик! И така беше през доста дълъг период от време (докато гледах).

2 часа почивка и отново време за boarding. Обаче вече не сме в голяма машина – вече сме второстепенна дестинация. Което означавам че излязохме от терминала и се качихме на автобус. Той обикаля, обикаля, и ни закара до един A319-100. Не че е лиша машината – даже е прекрасна. Обаче аз идвам от нещо много по-голямо и се чувствах като в лагерница. Прибавете и лошото време.

Обаче пилота беше майстор. Това беше толкова меко кацане, че ми идваше да го разцелувам. Разбира се, бях изтощен – излетях в петък вече и кацнах в събота около 22:20 (-10 часа разлика).

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

Чувствам се добре в България!

 

Днес се чувствам по-добре. Още подсмърчам, покашлям, но рядко.

Събудих се към 6 и прекарах почти час под душа. Така или иначе закуската я „сервират“ (т.е. слагат тостера и филийките) в 7. Е, всъщност има и чай, кафе, мляко, даже вода. И някакви корн флейкс. Ама няма никаква мърша.

Имаше нужда от малка интервенция в офиса, после скайпнах и до дома. Все пак се стегнах по-бързо – днес първата сесия е от 9:00. Когато излязох, навън не валеше, но беше мокро. Малко преди да стигна до Moscone не-валенето приключи. Добре че съм бързоходец, пък и долу-горе добре екипиран.

Първата лекция, на която отидох , беше „Trends in Database Administration and the Changing Role of the DBA“ на Michael Corey. Евала, много готин пич. Каза, че работи с Oracle от версия 3 (!) и помни времената, когато Лари Елисън е вдига телефона на съпорта. Абсолютно цялата информация за Oracle е била 3 книги и всичко е било ясно. Сега документацията, ако се разпечата и подреди на рафтове, ще запълни едната стена на конферентната зала; а другата стена се запълва от книги на други автори, които обясняват какво по-точно има предвид документацията. И пак не е ясно кое как става. И много други интересни неща – как да си търсим DBA, защо няма да го намерим лесно; как да го задържим, защо ще иска да избяга; много размишления, по много DBA-related теми. Той има консултантска компания (много добра, както разбрах по-късно).

След това мислех да ходя на „Real-World Performance Questions and Answers“ – панел на Weal-World Performance Group. Но ми звънна Юлиян Дончев и си спретнахме малка среща. Говорихме за живота, смъртта, и базите от данни; Oracle, славата, конференциите, e-mail-ите, мениджмънта и какво ли още не. Заведе ме в ъгълчето на Oracle Certified хората, където ми дадоха OCM дънкова риза. Заедно с другите подаръци и покупки, започвам да се чудя как ще събера всичко в куфара. Май утре няма да си показвам носа из града – ако купя още нещо, ще трябва да си го нося в джобовете.

После отидох с голяма надежда на „Oracle Data Guard Switchover and Failover Internals: How Fast Can You Go?“ – разказ на Интел как го правят. Нали вече казах, обичам разказите на хора, които вече са минали и настъпили мотиките. Обаче ядец – системата, за която говореха, беше безумна проста, направо срамота. Intel си държат супер критичната Factory Automation database на някаква Windows машина (правят failover cluster посредством MSCS!!!) и имат 1 (1!) async remote standby, както и репликация на storage. После взеха да обясняват как планират да направят синхронен standby и каква далавера ще имат…. очаквах повече.

Бързо хапване, последни подаръци, и следва Craig Shallahamer с неговата SQL Elapsed Time Analysis. Лекциите на тоя пич са малко разхвърляни, иска да каже много неща за малкото време. Ама ги изнася с такава страст и толкова нагледно – голямо удоволствие. Пък и доста ги разбира нещата – като захапе един проблем, го изследва „до кръв“. Абе евала.

Последната за OOW’11 сесия беше една от най-яките: „Under the Hood of Oracle Automatic Storage Management: Fault Tolerance“ на Alex Gorbachev. Е той направо ме разби. Знае и разказа супер много неща за ASM, Failover, rebalancing и т.н. И, за разлика от Оуен Хюз, успя да обясни защо Exadata не е абсолютен disaster за availability. Мислех, че в една Database Machine, ако отпадне един диск, преди да мине rebalance, риска от загуба на всички данни е огромен – отпадането на само още един (от 156). Оф, май не стана ясно. Както и да е, има проблем, но далеч не е толкова огромен, колкото мислех. След всичките обяснения направи и live demo с 42 диска (виртуални, на макбука му).
Един от интересните факти, които не знаех – каквото и redundancy да имате в ASM групата, базата (DBWR/LGWR/ARC/…) е тази, която пише на 2 (или 3) места. И винаги се чете от едно от копията, което се нарича primary; mirror екстента не се ползва за четене. Освен при stretch clusters, ама това е космическа технология.
Замисляли ли сте се, че система с 2 failure groups е пълен провал от гледна точка на availability? Ако отпадне едната група, дори и да е почти празна, другата не може да направи rebalance.

* * *

OOW ми подейства като наркотик. Мощен, опияняващ. Не исках да свършва. Още една сесия, още нещо ново… Като страхотен купон. Представете си най-якото парти. И на всичко отгоре продължава 5 дена. Нооооо….

Сещате ли се за онова чувство на празнота, което се случва след като спре музиката? И какво – само толкова ли беше? И изведнъж те затиска умората. Пък трябва и да се прибираш.

И така, сега съм емоционално изтощен от купона. И – ах – колко искам да се прибера, да съм си вкъщи! Само дето прибирането няма да е 10 минути – утре отлитам в 9 вечерта и (с 2 часа престой в Мюнхен) ще се прибера в 10 вечерта в събота (дано). Стискайте палци за безпроблемен полет. Че като знам какъв ми е късмета с вечерните полети на Луфтханза до София

 

Събудих се с противна кашлица. Седем без десет – тъкмо навреме. Станах и влязох под горещия душ. Обичам да се мотая в банята, винаги откарвам минимум половин час. Този път не направих изключение. И без това първата лекция за днес е в 10:15…

Излязох от душа и погледнах на малкото екранче на часовника колко часа е в София. Това е удобството да имаш часовник, способен да показва 2 часови зони едновременно – не се налага да смяташ.

WTF? 15:30??? Ъъъъ…. ама то било пет и половина, а не седем и половина. Баси, как можах да се объркам толкова жестоко? А след душа съм свежарка, дума не може да става да заспя. Тотално прецакване. Натисках възглавницата още час, после се отказах и станах. И без това напоследък не знам кога ми се спи и кога не… ще изкарам още един ден така.

(всъщност за сега, 21:00 часа, си се чувствам долу-горе добре. Явно наистина съм се наспал)

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

Днес ми е ден за подраняване – пристигнах около 9:00. Запътих се към третия етаж, за да си взема четвъртия чай за деня (след 3 в хотела). Когато пия чай почти не кашлям. Обаче не ги изкарват толкова рано. Слизам на второ ниво и – изненада! Познато лице, Милена на щанда User Groups, даже с още един колега от България. Разпънахме локума. Стана дума за концерта тази вечер (Sting и разни други) – безплатен за участниците в OOW, но имало голямо търсене на билети на черно. Аз и без това няма намерение да ходя – с тази кашлица и толкова домашни за вършене всяка вечер. Дадох им билета, ако някой прояви интерес, да го взема for free.

Към 9:50 успях да се уредя с чай и се запътих към първата сесия за деня – Oracle Active Data Guard: Lessons Learned from Real-Life Implementations. От любимите ми, real life истории, разказани от клиенти, които наистина са се борили с това. За съжаление в България няма много такива сесии, да не кажа хич (редките изключения включват Нено от Бела, който, обаче, се отказа да говори).
Както и да е. Сесията започна на шега с изречението „This is not an Exadata presentation”, което беше посрещнато с бурни аплодисменти. Сигурно половината database сесии тази година са посветени на Exadata.
Тук имаше истории на двама клиенти, все големи фабрики. Първата приказка беше всъщност как да подкараме Active Data Guard да работи за Peoplesoft, Hyperion и OBIEE. Доста applicatoion-specific. Втория клиент, обаче, разказа по-интересна история с реални мотики. Примерно замисляли ли сте се как се държи performance tab-а на Enterprise Manager върху ADG база? За последния час показва както трябва (нали взема данните от ASH), обаче назад дава данните от Primary базата – тях намира в dba_hist_*. Други логични проблеми са, че на такава база няма auditing – нали няма къде да пише. Също не работят logon triggers и, много яко, автоматичното прекомпилиране на невалидни обекти. Всичко това е логично, ама трябва да се сетиш. И други проблеми споменаха, ама да не ви отегчавам.

След това отидох да послушам за How Oracle GoldenGate Breaks Scalability Barriers at Western Union. Куца хава – и тяхното приложение е проектирано за active/active от самото начало. Въпреки това споделиха интересни неща. А, имали release всяка седмица, major release всеки месец – всичко това без downtime благодарение на Golden Gate.

Хапнах много набързо и се засилих към една стара любов – Understanding Oracle RAC Internals. Честно казано, останах леко разочарован – не разказаха кой-знае какви internals. По-скоро говориха за CRS/HAS като цяло. Но поне си поприпомних някои неща. А, и разказаха, колко нови фичури има в 11.2.0.2. спрямо 11.2.0.1. Примерно вече node fencing (обикновено) не предизвиквало node eviction, т.е. не рестартира нода, а се опитва да рестартира само CRS. Ми така де, има машини дето само PSOT-а им е 10-15 минути. Ненормална работа.

И след това – 2 часа дупка. Нито една сесия, на никаква тема. Защото чичо Лари има keynote и всички трябва да слушат него. Е, аз пък не искам да се блъскам да го слушам. Направих няколко тегела из двете огромни изложбени зали. Баси, всеки втори подарява iPad. А ако спечеля, ще го пратите ли в България – ами не, може само в щатите. Ами дръжте си анкетата тогава.

Срещнах Юлиян Дончев на щанда на Accenture и разпънахме и с него малко лакърдии. После се пощурах още малко и отидох на последната за деня сесия – So You Think You Know Everything About Oracle Partitioning? И тя трябваше да е разказана от клиент, ама пусто в последния момент не успял да дойде поради лични причини. Разказа я един пич от Oracle. Знаехте ли, че при exchange partition колоните на двете таблици трябва да са с еднакъв тип и брой, но може да са с различни имена? Не че е много полезно, ама кой да предположи.

Ми толкоз. Вечерях пържола от риба тон с някакви зелении покрай нея. Както и салата „цезар“, която всъщност беше листа от айсберг с две-три рибки и малко сосец. Сега ще си направя календара за утре, ще си напиша домашното и така. Остава само един ден и после край на празника. Ех…

 

Днес съм малко по-добре

Успях да спя цялата нощ и сутринта не бях скапан. Да, кашлям и имам досадна хрема, но все пак съм в прилична форма. Пък и времето се пооправи – по обяд даже имаше слънце, за малко. Но сега пак вали, ситно и гадно. И подухва хладно.

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

За днес пак си харесах по 2-3 лекции на слот. Но си отделих и време на наобиколя единия Exhibition hall – да видя какво, аджеба, показват толкова. Обикновено си правя програмата вечер, като избирам всички лекции, които ми харесат. Сутринта на свежа глава си набелязвам най-интересните (до 3 на слот). И после решавам на място.

По пътя минах да нагледам джаварите, за които пита Иван. И те са затворили цяла улица и 3 огромни хотела (по 20-30 етажа), включително Хилтън. Ей, джавар да си…

А вечер пият бири на улицата

Толкоз за Java one. Аз си отидох пак до Moscone. Замисляли ли сте се колко вида спонсори може да има събитие като OOW? Marquee sponsor, Diamond sponsors, Premier sponsors, Elite sponsor, Grande sponsors, Platinum sponsors, Golden sponsors, Silver sponsor, Bronze sponsors, Signature sponsors, Media sponsors – 11 вида.

Иначе днес започнах деня с лекция на Christian Antognini: Challenges and Changes in the Oracle Database 11g Query Optimizer. Много знае човека (което си личи и по дебелата книга, която е написал). Да знаете, че в 11.2 системните статистики са яко преебани, трябва да се слага пач 9842771. И други интересни неща – примерно ако искате да махнете индекс, щото ви изглежда излишен, можете да го маркирате като invisible. Така оптимизатора няма да го използва. Ако всичко върви ОК, след 2-3 дни или седмица (или месец), може спокойно да го изтриете. Е добре де, това всеки го знае. Обаче след това базата се смачква от IO. Ха, ядец! Това става защото индекса се използва от БД (а не от оптимизатора) за проверка на foreign key, дори когато е invisible.
И други полезнотойки каза, ама ме мързи да ги пиша.

След това отидох на Performance of Oracle Database 11g Release 2 Flash Cache with Solid-State Disks. Честно казано, замислям се за една такава евентуална покупка. Има два начина да се използва SSD от Oracle – или като разширение на buffer cache (ама само в 11.2 и само на Solaris и OEL – ползвателите на RHEL няма да се облажат); или да бухаш файлове на SSD и да се кефиш колко бързо работи. Така поне обясниха хората от DELLL, които явно бяха изпратени насила да говорят за това. За съжаление след интридукцията, нещата станаха твърде рекламни. Язък за похабения слот…

Обяда не беше организиран аналогично на вчера. Сандвич (в случая с пуешко), някаква салатка (в случая предимно жито, нахут и царевица) и курабийка. Абе позапълва стомаха.

После ходих на още една сесия, изнесена от клиент: Oracle Database 11g Release 2 and Oracle GoldenGate: Best Practices at Banka of America. Полезна беше. Тоя Golden Gate явно става за употреба. Хората си премахнали downtime-а по време на release (защото ги имали много често – 6 до 9 пъти годишно!). А също и при database upgrade, platform/hardware change и други, ама това не са го пробвали – не се е налагало от както имат Golden Gate. Лично синиър дибией от тая голяма фабрика ме убеди (след като попитах), че Golden gate няма проблеми с огромни транзакции от рода на няколко милиона update-а, за разлика от streams/logical standby.
В крайна сметка, щом върши работа на Bank of America, трябва и при нас да проработи.

След това се разходих из изложбената зала – огромна площ с павилиони на кой ли не

Всеки се надпреварва да дава награди, само и само да се запишеш. От тениски и флашки, през Blackberry Play и най-вече iPad2 (всеки трети павилион), Apple TV (EMC2) та чак до мотоциклети и автомобили. Само тука да попълниш един малък въпросник… и после да те наспамим. Аз успях да си отмъкна плакат с 11g Data Dictionary от TUSC, както и някоя тениска. Успях да разгледам на живо т.нар. database appliance и да поразпитам един инженер за подробности. Здрава машинка, ама яко скопена, да не вземе случайно да се конкурира с exadata. Има 12 TB raw disk storage, обаче го използва задължително в ASM групи с тройна защита – демек 4 TB. И преди да си помислите, че все пак не е малко, идва следващата подробност – понеже тая работа е много умна и всичко сама прави, при инсталацията ви пита къде ще си правите бекъпа – на диск или лента. И ако сгрешите да кажете „диск“, тя си разделя наличните 4 TB на 60% flash recovery area и 40% data. Демек от всичките 12 терабайта разполагате с 1.6. Баси, баба ми има повече място на харда си!
Други подробности са, че има 4 SSD диска по 72 GB , които си прави в дискова група REDO, отново трайно защитени – демек 96 GB. Хем е много за redo, хем малко за temp. И не може да си ги преконфигурираш в normal redundancy – ставаш unsupported.
А какво правим ако няма място? Ами компресираш! Толкова добра компресия имаме… Не, няма експанжън, поне за сега (но като гледам, може и да има – всеки от сървърите има по 2 e-sata конектора забутани в едно ъгълче на задния панел).
Друг интересен щанд беше на FusionIO. Тия пичове твърдят, че правят flash памет от NAND чипове. Поиграх си (физически) с една PCI-E карта, на която имаше 1.8 TB. Твърдят, че имат карти от 320 GB до 10 TB (на една карта!!!). За скоростта на четене няма нужда да говорим. Обаче не ме пуснаха да си тръгна с картата – дадоха ми само тениска.

После отидох да слушам един много земен DBA от Cisco, който разказа за неговата борба с Oracle RAT (Oracle Real Application Testing Meets the Real World). Разказа как се оказали с един EBS, който се задъхва, щото базата му работи на RAC клъстер от 3 HP Integrity Superdome със 128 core-а на всеки, 512 GB RAM и 8000+ сесии. Решили да минат на по-прости сървъри, ама повече, и си направили RAC от малко по-съвременни 12 машини. Разказа борбата с RAT-а, полезно беше.

За последно отидох на Making the Most of Solid-State Disk in Oracle Database 11g. Много по-полезно от рекламинте изцепки на Dell от сутринта. Човека наистина си поиграл, пробвал, тествал, мерил. Най-интересното, което каза, е че няма никаква далавера да си слагаш online redo logs на SSD. Правил няколко опита, файда йок. Иначе за TEMP далаверата е голяма, особено ако имате много multi-pass sorts (конто няма, не е видял reporting). А ако си качите и цялата БД, направо хвръква – както производителността, така и цената. Обясни долу-горе и как работи другия вариант на употреба на SSD – flash cache, демек продължение на buffer cache .

На края една снимка на великата лодка на Oracle, която плувала три пъти по-бързо от вятъра (т.е. с 30 км/ч при вятър от 10 км/ч).

„Платното“ е толкова високо, че не се събира и половината в Moscone West, така че са го сложили на страни. Ама се чудя – колко ли са псували докато го вкарат вътре и го закрепят…

И на края, още малко „наблюдения“
- тук с всяко ядене (без значение дали са сандвичите в палатката, или нещо в ресторант), сервират ледена вода – с много лед вътре. Което е много приятно, ако не си болен/настинал като мен
- хората не се притесняват да сядат по земята – в коридорите покрай залите, в лобитата, навсякъде. Сядат си, вадят таблета и цъкат
- като казах таблети – те са супер масово явление. Видях много повече таблети, от колкото лаптопи. И като се замислиш, удобни са. Мен ме мързи да влача лаптопа, защото и без това не мога да си водя записки на него – няма да издържи. А всеки трети или четвърти човек цъка на таблет

 

Събудих се смачкан.

Нещо се опитва да ме гази – някаква настинка или нещо по-гадно. Не е много добра идея, особено на 12000 км от дома. За сега се държа, ама и времето не помага много – студено, смръщено, и цял следобед вали – слабо, но гадно.

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

(Ето обещаната снимка от хотела: така изглежда моята стая)

Хапнах continental breakfast и изпих първия за деня чай. Помотах се малко и тръгнах към Мъскони (така се произнасяло Moscone). За днес си бях харесал толкова сесии, че трябваше да се раздвоя и разтроя. Всъщност в един момент има 98 (!!!) паралелни сесии.

По пътя станах свидетел на любопитна гледка. Едно от нещата, с които е известен Сан Франциско са т.нар. cable cars, или трамваи, които неуморно катерят баирите. Така и не се бях замислял как обръщат. А то ставало ръчно – пристигна на една хоризонтална платформа, „ватмана“ слиза и буквално го изтиква да застане към обратната релса. Платформата е дървена, но явно лагерува аксиално върху добре смазан механизъм:

Започнах с „Think Outside Your Interconnect“ When Optimizing Your Oracle RAC Environment. Оказа се същия индиец, който вчера говореше неподготвен за Result cache – май спомена че е шеф на индийската юзър група. Ами какво да кажа, има много опит (каза, че е деплойнал над 100 клъстера, най-големия е 12 нода), ама има някой пропуски в основните термини. сподели неща от опит, полезни, ама и разни глупости наговори.

След това отидох на Successful Oracle Database 10.2 to 11.2 Migration with Oracle RAT – съвместна сесия на двама ДиБиЕй-и от CERN и Product Manager Director-а на RAT в Oracle (RAT -Real Application Testing, a.k.a. capture/replay). Надявах се след индийския диалект да има нещо по-лесно за слушане, но не би – тежък френаски и още по-тежък ъъъъ…. примерно чешки? (Katarzyna Dziedziniewicz-Wojcik). А, да, и пак индийски – директора от Oracle се казва Prabhaker Gongloor. Обаче хората си знаеха материята. Споделиха някой мотики, които ако знаех преди 2 месеца, щях да постъпя по друг начин. Най-много се зарадвах, че има решение за един мой проблем, който Прабхакер обеща да ми изпрати. Да видим дали ще ме огрее, де. Че то на конференции лесно се обещава.

Знаете ли как се изхранват десетки хиляди хора за два часа? Всъщност да кажа, че има обяд за участниците. При регистрацията ти дават купончета, по едно за всеки ден (old scool, yea!). Та така, по обед около всички сгради, в които има лекции, се появяват едни хора с високи пръти, на които има табли LUNCH. Разположени са през няколко метра, така че просто трябва да ги следваш. Обяда е в ултра-огромни едни палатки, заемащи цяла голяма улица. Има избор от 2-3 вида сандвичи, по един на човек, с малко салатка и това е. Масите сигурно стигат за не повече от 1000 човека, но няма всички да обядват едновременно, я! Пък и околните паркове, градини, конферентни коридори и дори зали също стават за ядене на сандвич. Както и мноооогото exibition halls на кой ли не – включително NG:

А това е транспорта до по-големите хотели:

Има 5 различни линии, които тръгват от Moscone West. Така и не знам коя минава покрай моя.

Така де. Следобед минах на вълна Golden Gate. Първо слушах GoldenGate: Customer Panel: Achieving Zero-Downtime Upgrades and Migrations – много стреснат лектор, ама наистина го е направил и сподели как става. Е, поне по-едрите детайли. Тази сесия беше в хотел InterContinental – зала InterContinental Ballroom B. Да не се бърка със зала Ballroom B в същия хотел, което е два етажа по-ниско и там си говорят за PeopleSoft. Ако не е ясно, разликата е в името – едната зала има името на хотела в началото. Яко, а?

После слушах пак клиентска история за нещо направено с Golden Gate: Active/Active в Thomson-Reuters. Фразата на деня: our application is designed for active/active from the beginning, so we do not have conflicts. Късметлии.

Замисляли ли сте се колко товар може да понесе един ескалатор? Доста:

След това се засилих към хотел Marriott Marquis за Deep Dive into Oracle GoldenGate 11g. Кой да предположи, че за hands-on lab трябва да се запишеш предварително? Тръгнах да влизам и ми казаха „Не сте в списъка, трябва да почакате да се освободи място“. Погледнах тълпата чакащи – петнайсетина човека – и реших, че няма да го бъде. Изтичах бързо до Moscone South, където слушах за хубавите нови фичури на 11g, които го правят много бърз. Фичури, фичури, ама повечето бяха опции. Абе рекламно се оказа.

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

Ресторанта с американска хране беше пълен, така че ядох италианска. И това приключва понеделника. Ще отхвърля малко работа и отивам да спя.

Приятен вторник!

P.S. Срещнах Jonathan Lewis и си поговорихме малко. Прекрасно е да слушаш британски английски! за съжаление той няма лекции тая седмица

© 2011 Master Yavor from Tryavna Suffusion theme by Sayontan Sinha