Уста Явор Тревненски

Правителството оцеля при седми вот на недоверие

Това чета в online изданието на вестник СЕГА. Това не е на първа страница, а е петата (!) поред новина за деня в секция “България”. Нарежда се веднага след “София проверява чистотата за конфликт на интереси”. Явно не е най-важното. Просто някакъв си вот.

Ми логично. Вече никой не вярва ни на правителство, ни на опозиция.

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

Сигурно много са се постарали. Там, в парламента. И двете страни са се подготвяли старателно, седмици наред. Управляващите са събирали де що има добри новини: представям си по една тумба чиновници във всяко министерство, които изписват успехите и предават заветната папка един час преди крайния срок на (секретарката на) министъра, за да я даде после той на министър-председателя. Опозицията - обратно, са набирали мощ в хулите си: представям си Костов казва на Абаджиев “остави този компромат, ще го използваме за вота”. Седмици наред кипи излишен труд и се хаби енергията на и без това не-много-енергичните бюрократи.

И всичко това отиде зян. Защото вече никой не ги гледа и слуша.

Read Full Post »

И така, от първата част стана ясно, че искам да получа много точно колко време е отнел даден процес, като имам дата на започването и завършванвето му. Първия интересен момент, за който се сетих е какво правим при промяната на часовника през пролетта и есента (т.нар. DST). За щастие Oracle се справя автоматично с този проблем когато се използва “TIMESTAMP WITH LOCAL TIMEZONE” (TSLTZ) (metalnik note 359119.1).

Понеже ми е много лесно да работя с тип DATE (там нещата са много прости), отначало си направих една функция, която да превръща подадените и TSLTZ в DATE и после - както си знам. Когато се извадят две DATE полета, резултата е дробно число, което се обаработва много лесно: цялата част е разликата между двете дати в дни, а дробната - в части от деня. Т.е. ако умножа (datе2 - datе1) * (24 * 60 * 60), получавам точно разликата в секунди.

Тук има две подробности: първо, така губим точността до секунда и второ, губим DST информацията. С второто се справих като нормализирах TSLTZ до гринуичко време преди да ги обърне в тип DATE:

(Aко ти е интересно, чети нататък…)

Read Full Post »

Покрай проекта за електрическото правителство витае въпроса за отговорността на ЕСОЕД за обработката и доставката на съобщенията документите, които пренася. Тук има две противоречиви изисквания. Първото е, че трябва да прекараме всички документи достатъчно бързо. Има определен интервал, в който можем да доставяме даден документ. Ако изтече, т.е. не успеем да го доставим, се случват лоши неща. Второто е една… хм… интересна закачка, заложена в чл. 18 от наредбата за ЕСОЕД и тълкуването му от МДААР, която не искам да коментирам.

Както и да е. В тази връзка имплементираме в системата много точно отчитане на времето. Първо, часовниците на всички сървъри са синхронизирани адски точно благодарение на СОЕВ - системата за отчитане на единно време, доставена от HP. После, много точно записваме кога един документ е постъпил в ЕСОЕД и кога сме успели да го изпратим (задължени сме по чл. 41 от наредбата). Освен това пазим и кога сме приключили с всички обработки, за да е ясно колко време документа се е бавил при нас и колко сме се опитвали да го изпращаме.

(Aко ти е интересно, чети нататък…)

Read Full Post »

При миграция към Oracle 11g има една малка, но дразнеща мотичка, свързана с timezone файла, използван от БД. Не мога да разбера защо DBUA, който прави толкова много и сложни неща, не се справя с това. Почти съм сигурен, че проблемите са политически, но не мога да схвана какви са.

Както и да е. Ако мигрирате от нещо по-старо от 10.2.0.4 към 11g, трябва първо да си оправите timezone файла. За доста относително съвременни patchsets (примерно 10.2.0.3 или 10.1.0.5) това става лесно с прилагането на patch bundle с opatch. Но ако имате шанса да сте на нещо по-старичко, като 10.1.0.4, нещата загрубяват.

Ето тук е много полезна следната metalink note: Applying “version 4″ Time Zone Files on an Oracle Database. В нея има една красива табличка с линкове и обяснения за коя версия какво се прави.

Enjoy

Read Full Post »

Пет…

Read Full Post »

Можете ли да си представите такова име на шивашко ателие:

Аз не бих отишъл точно там…

Read Full Post »

Колкото и невероятно да звучи, този път организаторите надминаха предишния. Предварителната програма е супер пълна с ценни неща и интересни лектори. Които, обаче, няма да коментирам. Просто не искам да се задълбочавам. Защото…
Малко са нещата, които могат да ме откажат да присъствам. Но точно на 25-и април сестра ми ще се омъжва. И така, за [...]

Read Full Post »

Преди почти 3 години написах статията за JABORAC. Там написах, че девелъпърите трябва да се обучават, за да разберат как работи БД. Но така и не стигнах до конкретни мерки. Е, правил съм някои опити, но нищо сериозно.

Един опит за сприятеляване на девелъпърите с Oracle DB прави Cari Millsap. Попаднах на неговия документ “For Developers: Making Friends with the Oracle Database“.

Много ми харесаха следните думи:

Speed is a vital feature of good software. Speed doesn’t just happen by accident. It’s a feature that you have to design into good programs.

Точно в десетката!

И като цяло четивото е полезно, макар и според мен да е малко трудно за един developer. Дано има някаква полза. Аз разпечатах няколко копия и ги раздадох на по-обещаващите колеги. Един от тях сякаш наистина прояви интерес

Read Full Post »

Най-простия начин:

expdp system@db schemas=abc directory=data_pump_dir dumpfile=abc.dp logfile=exp_abc.log
impdp system@db schemas=abc directory=data_pump_dir dumpfile=abc.dp logfile=imp_abc.log REMAP_SCHEMA=abc:def

После трябва да се оправят само грантовете от други към тази схема.
Не че е кой-знае какво, ама ми писна всеки път да се чудя какъв беше синтаксиса за нещо толкова елементарно. За това го пиша тук. Ако не те интересува - just ignore.

Read Full Post »

Аз се занимавам с Oracle databse повече от 9 години. Правил съм какво ли не. Дълги години поддържах една относително сложна система с 12 сървъра, които си говорят - това включва инсталация, ъпгрейд и т.н. После започнах да работя по “външни проекти” за клиенти на фирмата и там също съм правил бая инсталации и ъпгрейди. Инсталирал съм и съм ъпгрейдвал доста от възможните комбинации от 8.1.5 до 11.1.0.7. И съм забелязал, че едно: няма скука тука.

С други думи няма случай, в който една инсталация или ъпгрейд да е протекла от началото до края безгрижно. Винаги има проблем - винаги! Бил той проблем с ъпгрейд скриптовете, с инсталера, с инсталацията на ОС, инсталацията на хардуера, мрежата… Веднъж в една инсталация на един двунодов клъстер изгърмяха 3 (!) от четирите захранвания на сървърите (по 2 на сървър, за да са резервирани). И в общи линии си знам, че щом има инсталация или ъпгрейд - ще има проблем, няма как. Нали за това съм troubleshooter. То ако става с цъкане на next аз гладен ще остана.

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

Поне така беше до вчера.

Вчера (да, знам, че беше неделя) пачнах една система от 2 сървъра във failover cluster със 3 бази без грешка - от 11.1.0.6 на 11.1.0.7. Нищо не съм пипал по ОС (нито нещо се скапа без да го пипам). Ъпгрейда на двата oracle home-а си мина по вода с помощта на Oracle Universal Installer. Ъпгрейда на трите бази мина също толкова безгрижно, въпреки че са натоварени с всякакви компоненти. Нищо не гръмна.

Между другото, в Oracle 11 дори и прилагането на patchset към БД става с DBUA. Това е много удобно, защото assistant-а е доста стабилен и прави доволно количество предварителни проверки. Явно и самите скриптове са тествани доста. Евала!

И сега се чудя… след като всичко мина толкова лесно, дали да очаквам в най-скоро време тази система да се срине тотално?

Read Full Post »