Archive for the ‘MySQL’ Category

Проблеми при инсталиране на MySQL 5.6 върху Redhat/Oracle Linux 6.4

вторник, август 13th, 2013

Наскоро ми се наложи да инсталирам MySQL от пакетите от http://mysql.com на Oracle Linux 6.4.

Оказа се че има едно пакетче mysql-libs-5.1 което Redhat/Oracle Linux инсталира по подразбиране (защото postfix го иска). И то пречи на пакетите от mysql.com да се инсталират.

Ето рапорта за грешка който рапортувах на http://bugs.mysql.com

А за мен засега си реших въпроса като :

  1. инсталирах mysql-shared-compat-5.6-*.rpm
  2. използвах mysql -hi –replacefiles mysql-*-5.6-*.rpm

И сега чакаме 🙂

Гласувайте за грешката ако сте я видяли.

Награди Дарвин за MySQL грешки ?

петък, юни 26th, 2009

Не знам дали сте чували за наградите Дарвин, но според мен почина трябва да се разшири (понеже глупостта е универсална).

Ето и моя кандидат за награди Дарвин за глупави MySQL грешки. Това е една грешка в която човека се опитва да зареди Innodb библиотеката (неразделна вътрешна част от MySQL) като външна библиотека и да я използва през C интерфейса !

Far side of the world

събота, април 12th, 2008

Отивам !

В Далечния край на света. Обикновенно това се използва за нашата мила родина. Но аз съм щастлив че мога да го използвам за Сан Франциско (знам, ще ми кажете да нося цветя в косата си, ама няма как : гола глава съм).

Човек и добре да живее рано или късно (ако е в моя занаят) му се налага да отиде до Силиконовата долина (и нямам предвид резиденцията на Пайнер в Димитровград !)

Шантавото е че съм бил в двата края на Пътя (Ню Йорк <-> Лос Анджелес) ама не ми се е отдавал шанс да го пропътувам в кабриолет от 60-те 🙂

Нервно ми е : все пак е доста път. И съм спокоен : летя с уважавана авиокомпания.

Имаше една (любима) сцена в Reservoir dogs на Тарантино : седят си пичовете на закуска и си обсъжат песента “Like a virgin” на Мадона. И единия обяснява : “намерила си лирическата героиня един пич. И той бил толкова голям че макар че тя била видяла какво ли не в секса я боляло като че и е за първи път. Демек : като девица”.

Ето така се чувствам 🙂

If you’re going to San Francisco
be sure to wear some flowers in you hair ..

Още по света и у нас

четвъртък, март 13th, 2008

Днес ми е дълъг ден : станал съм в 6:00 Ижевско време (бг + 2часа) и последния ми полет каца в София в 23:55. Това прави 20 часа мотане по летищата.

Добре че се навих този път да пътувам през Виена : на виенското летище има безплатен интернет и за притежателите на карти Diners Club има и друга изненада : има специална (много тиха и добре климатизирана) зала ! Веднъж да има някаква полза и от тази карта (дори и в момента пиша от нея).

Иначе какво да кажа за Русия : това е една страна дето хем ме изумява, хем ме кара да се чувствам като у дома.  На моменти все едно че виждам България (един по-добър модел от моето детство). Но има едни моменти в които все едно познатите ми хора от едно време си дърпат маските и отдолу изскачат пипала на извънземни : толкова са чужди и различни.

Иначе успях да надпия един истински руснак ! Стигнахме до фазата “ти мене ужааш ли мъ”, а пък аз си бях трезвен като кисела краставичка.

Но този път освен напразното разкараване и приказки успяхме да  отметнем доста работа. Никога не бях се връщал от командировка с чувството че не съм си загубил времето досега ! Хубавото беше че дойдоха доста хора с които исках да говоря : прекия ми началник и едни “големи хора” от Sun. Така че се получиха чудесни разговори и решихме доста проблеми.

“Големите хора” от Sun дойдоха с частен самолет ! И ние ги посрешнахме както подобава : инструктирахме русите да им наемат лимузина. Оказа се че към лимузината вървят и двама “слуги” с ливреи и червен килим !  А пък и после единия русин си призна че са му предлагали и интимни услуги към лимузината, ама той будалата отказал ! 🙂  Абе майтап. И се оказа че не излезе и скъпо : нещо като 200-на EUR за целия салтанат.

Дааа : голямата фирма си има някои предимства !

В Русия съм ! В Русия съм !

вторник, март 11th, 2008

По-точно в Ижевск. Започвам да се чувствам все по-вече у дома в Русия : това ми е втория път.

Вчера колегите ме водиха в музея Калашников. Оказа се че в този град се произвежда оръжие от 200 години !

Вече официално сме част от Sun

събота, март 1st, 2008

Сделката вече е финализирана. Няма 6-5  : официално сме част от Sun.

Преживях първото си корпоративно сливане. Надявам се в целия този вихър на промени да успея да хвана някое листенце и за мен лично.

Макар че вятъра не престава да духа : примерно мен ще ме издуха другата седмица до Ижевск в Русия да чакам фирмения самолет с няколко баровци в него. Но пък за утешение руските колеги ми обещаха да ме заведат до музея “Калашников” ! Дано да има интернет ! Ще има много снимки за блога 🙂

Не знам какво им става на тези руснаци. Но го приеха като лична обида като попитах за хотел. Не можело : идвали сме им на гости : как така ще спим на хотел !?? Затова ще трябва да се разходя до Министерство Внутренных Дел за да си регистрирам визата : нещо което хотела би направил за мен иначе автоматично. Май само в Москва не е така (там този обичай явно е замрял).

А след това отивам на MySQL Users conference and Expo. Можете да се обзaложите че тази година (със Sun и т.н.) ще е доста интересно. А и няколко много интересни и умни хора ще говорят (тук, тук и тук). Така че ако някога сте си мислили да отидете на конференцията, сега е много добър момент.

А, за малко да забравя : назначили са ни SunVisor-и : на всеки човек от MySQL назначиха по един от Sun : да можем да го питаме разни неща които нормално бихме питали колегите си. Моя се казва Paul Sandoz: много свестен човек, който живее във Франция.

Sun купиха MySQL

четвъртък, януари 17th, 2008

Sun купиха фирмата за която работя (MySQL).

Ето как за един миг се озовах във вихъра на истинско американско корпортивно сливане. Със всичките му неща както си се полага : телемост с новия CEO, пълна неяснота кой как кога и какво и големи и малко изкуствено изглеждащи усмивки на лицата на всички.

Не ме разбирайте погрешно : сигурно като се уталожи дима ще се окаже че това е добър ход и за MySQL и за Sun. Просто в момента ври и кипи. А знаете че когато един котел ври и кипи мръсотийките изплуват най-отгоре.

Много силно съжалявам че не можах да пътувам до тази среща на фирмата (пипнах едно леко протичаща и бързо свършваща, но силно заразна болежка точно в деня преди да замина и се наложи да си връщам самолетния билет).

Странни грешки в С

сряда, юни 20th, 2007

Невероятно нещо са това компютърните технологии : дори и нещо с което си вадя хляба от толкова години (С компилатора) не престава да ме изумява.Ето две грешки на които се натъкнах докато се борех с MySQL bug #27383:

  • Оказва се че оптимизатора може да реши да оптимизира по странен начин операциите с указатели. Примерно това:
    int foo(float *f)
    {
      int i = 23;
      f= (float *)&i;
      *f = 5.0;
      /* A float* cannot point on the same address as int*. */
      return i * 2;
    }

    може да бъде оптимизирано до това:

    int foo(float *f)
    {
      *f = 5.0;
      return 46;
    }

    Забелязвате ли как резултата който се връща от функцията не е верен ? Това се получава понеже според ISO C указатели от различен тип не могат да сочат към същия адрес. И понеже според това правило няма шанс присвояването на 5 да смени резултата от функцията, то просто се прескача.
    “Лечението” в този случай е да се променят данните само през указател от същия тип, т.е. f от горния случай трябва да стане int *. И тогава няма проблеми. Ето малко описания на английски.

  • Не винаги резултата от сравнение на две числа с плаваща запетая е един и същ. Ето един пример:
    #include <stdio.h>
    void test(double x, double y)
    {
        const double y2 = x + 1.0;
        if (y != y2) printf("errorn");
    }
    
    void main()
    {
        const double x = .012;
        const double y = x + 1.0;
        test(x, y);
    }

    Когато тази програма се компилира с gcc с оптимизация и се стартира на Intel базирана система тя печата error. Това се получава понеже y2 и y се оптимизират така че всъщност не заемат място в стека : те си седят в FPU регистрите на процесора. И понеже тези регистри са с по-висока точност отколкото данните от стека при предаване на параметри при викане на test() се получава и разликата.
    “Лечението” пък на тази грешка е като се използва volatile : т.е. “се изключи” използването на регистри за y2 и y. Това може да позабави програмата, но поне ще я накара да работи вярно (което е за предпочитане май 😉 ).Ето малко повече информация по въпроса.

Дребно но много полезно “великденско яйце” в mysql (клиентската програма)

вторник, май 29th, 2007

Искало ли ви се е някога да видите какъв тип са колоните на resultset-а който MySQL връща ?
Най-лесния начин (за който се сещах досега) е да си направите view и да кажете DESCRIBE.
Проблема при този подход е че имате едно излишно нещо (view-то) и освен това той не работи за всякакви заявки.

Но се оказа че има и по-елегантно решение на проблема : “mysql -T”

Документацията на mysql за -T (–debug-info) е повече от неясна :
” Print some debugging information when the program exits.”.

Но това не е всичко : всъщност тази опция е много полезна :
преди да покаже данните печата и метаданните за колоните на SELECT заявката.
Ето как изглежда това :

mysql> select * from t1;
————–
select * from t1
————–

Field 1: `a`
Catalog: `def`
Database: `test`
Table: `t1`
Org_table: `t1`
Type: LONG
Collation: binary (63)
Length: 11
Max_length: 1
Decimals: 0
Flags: NUM
a
+——+
1
2
+——+
2 rows in set (0.00 sec)

Какво представлява Join Buffer Cache в MySQL

сряда, април 4th, 2007

Предговор: От време на време ще се опитвам да обясня това което съм разбрал за различните технологии в обработчика на заявки в MySQL с думи прости (така че да не ги забравя). Това е първото такова обяснение.

Представете си че имате JOIN на две таблици :
SELECT t1.a, t2.a FROM t1, t2 WHERE t1.a = t2.a.

Сега си представете че нямате индекс по t2.а. Това означава че (почти) нямате как да изпълните тази заявка освен като :

За всеки ред от t1

Вземи ред от t2 и провери условието t1.a = t2.a

Изпрати реда към резултата (клиента)

Вземи следващ ред от t2

Вземи следващ ред от t1

Този ред на изпълнение означава че t2 ще бъде “прочетена” от край до край толкова пъти колкото реда има в t1. А това може да бъде МНОГО !
Затова на помощ ни идва Join Cache (не знам как да го преведа : свободен превод е “събиране и повторна употреба (буфериране?) на редове от JOIN”).
Целта е да се опитаме да намалим броя пъти които t2 ще бъде прочетена от край до край.
Това става (естествено) на цената на използване на малко допълнителна памет (в MySQL размера на тази памет се задава с параметъра join_buffer_size).
Идеята е : вместо всеки път да се чете t2 да запишем част от t1 в паметта, така че да можем, вървейки по t2 да обработим наведнъж няколко реда от t1 (колкото има в паметта).

Алгоритъма е следния :

За всеки ред от t1

Записваме в буфера реда от t1.
Ако не сме успели да запишем реда (свършило е местото в буфера примерно)

Изпълняваме под-програмата “обработка на буфер”.

Край на условния блок

Вземи следващ ред от t1
Изпълняваме под-програмата “обработка на буфер”.

Подпрограма “обработка на буфер”:

За всеки ред от t2

За всеки ред от буфера проверяваме условието (t1.a=t2.a)

Изпращаме реда към резултата (клиента).

Вземи следващ ред от буфера

Вземи следващ ред от t2
Изпразни буфера.

Край на подпрограма “Обработка на буфер”

Както се вижда използвайки join cache броя на четенията на t2 е толкова пъти по-малък колкото реда от t1 “се побират” в буфера : т.е. ако в буфера се побират (примерно) 1000 реда от t1 това означава че t2 ще бъде прочетена (примерно) 2 пъти вместо 2000 пъти !

Има и странични ефекти за жалост : един такъв страничен ефект е че не може да се използва подреждане по индекс, т.е. ако резултата ни трябва подреден по някакъв начин ще трябва да си го сортираме (използвайки временна таблица) след това.
Освен това този метод може да се приложи само ако условията върху t2 не зависят от трета таблица (ако я има).
Като казах “трета таблица” метода може да работи и в заявки с повече от две таблици. Можете да видите един такъв пример с три таблици и допълнителни пояснения тук.

Но въпреки ограниченията си този метод може доста да помогне в случаите които е приложим.