Записи с меткой «DBMS»

SEDая древняя магия

Posted: 2014-05-13 in IT
Метки:

Три года назад я уже писал заметку, как можно обрабатывать большие выгрузки данных с помощью sed.

Недавно у меня возникла схожая задача: подготавливать файлы с тарифными планами для телефонной станции. Выгрузки эти довольно громоздкие, и вручную их обрабатывать слишком уж долго. Проблема в том, что присылают тарифы обычно в виде XLS-файла с кучей полей, с русскозыячными названиями направлений, тогда как телефонной станции нужен csv-файл, содержащий названия направлений транслитом, точные наименования полей в заголовке и ряд требований к разделителям в итоговом csv-файле.
(далее…)

Реклама

UTM5 и аццкая БД

Posted: 2011-10-21 in IT
Метки:

ISP, биллинг, БД на 20 Гб и практически не работающие внутренние отчеты. Точнее работающие, но очень уж долго. Страшно ? Нет ?! Ну ладно, читаем дальше. …

(далее…)

TruЪ ЫнтЫрпрайZzz…

Posted: 2011-07-20 in IT, Software
Метки:

A: дык Оракел — это же труЪ ЫнтЫрпрайз типа

D: ага, ага…. в 10-ом две тулзы для импортаэкспорта базы — imp/exp и impdb/expdb с несовместимыми форматами дампов. Правильно, первая не экспортирует поля float и double, вторая не работает с xmltable. правильно, у нас в базе есть и то, и другое

Гы !

Нашел шикарный цикл статей про сложные случаи отладки производительности запросов в M$SQL.
http://www.sql.ru/blogs/somewheresomehow/999
http://www.sql.ru/blogs/somewheresomehow/1000
http://www.sql.ru/blogs/somewheresomehow/1001

Когда я просматриваю различные форумы по SQL Server, я часто вижу вопросы от глубоко озадаченных пользователей. Они нашли медленный запрос или процедуру в своем приложении. Переместили этот пакет из своего приложения в SQL Server Management Studio (SSMS), чтобы проанализировать и обнаружили, что ответ от сервера приходит мгновенно.

Изначально в далеком дремучем прошлом, SQL Server включал в себя некоторые действия, которые нарушали стандарт ANSI для SQL. С выходом SQL Server 6.5 Microsoft представила все эти SET опции (кроме ARITHABORT, которая была уже в версии 4.x), чтобы дать возможность пользователям использовать SQL Server в ANSI совместимом режиме. В SQL 6.5, нужно было устанавливать эти опции явным образом, чтобы получить поведение соответствующее ANSI, но с версией SQL 7, Microsoft поменяла значения по-умолчанию для клиентов, которые использовали новые версии ODBC и OLE DB API. SET опции все еще остаются, для обеспечения обратной совместимости для старых клиентов.

По ссылкам много ахтунга, всем, кто пишет код или админит серверы под M$SQL — к прочтению обязательно.

CSV-2-SQL

Posted: 2011-03-21 in IT, Software
Метки:

Итак, есть такая задача — перегрузить данные между разными базами данных. Причем совсем разными. Например, из DBF в MySQL. Или из древнего как говно мамонта Paradox (и совершенно уёбищно кривого) в MSSQL. Или из Cronos в PostgreSQL.
(далее…)

M$ SQL 2005 — же-е-е-сть…

Posted: 2010-04-15 in IT
Метки:

Понадобилось тут создать тестовую базу на основе рабочей, восстановив её из ночного бэкапа. Восстановил первый раз — нет нужных данных. Я в шоке. Второй раз. Бля, наверно не выспался. Третий раз. Ну нет, и хоть тресни… Восстановил копирование рабочей, ОК. Полез разбираться, чего за нахер, почему в бэкапе нет нужных данных — и весьма конкретно охуел.

Блджад, перестал делаться бэкап у M$SQL-сервера.
Делалось оно через отдельную встроенную учетку SQLServer, парольная политика конкретно для этой учетки была выключена нахх (ибо для встроенной учетки с 20-символьным паролем она нах не нужна, да и истечение пароля на такой учетке приведет к нарушению бэкапа в будущем), все работало как часы больше года. С какого-то момента стало не зайти под этим пользователем. В логах ничего криминального не нашел. Пока пароль не сменил — ничерта не работало. Все секурити-патчи стоят. Ну вот что, скажите мне, что могло в этом несчастном сервере поломаться ? Обычная встроенная учетка SQL Server, используемая сугубо для выполнения команд типа BACKUP DATABASE локально, где ломаться по идее просто нечему.
И это еще один из самых приличных серверных продуктов Microsoft…

В связи с этим вспомнился похожий случай — когда бэкап другого подобного сервера, но более продвинутой версии, делался встроенной службой SQL Server Agent. Все работало года два вообще без нареканий, после чего в один прекрасный момент у заданий (SQL Server Agent -> Jobs) слетели владельцы. Соответственно, нихера не бэкапилось, никакие оповещения не срабатывали, только изредка в евент-логе появлялась скромная запись, сообщающая, что такой-то логин не смог выполнить такую-то команду. Учитывая, что неправильный ввод пароля пользователем в учетной системе дает почти такое же сообщение в логе, то становится понятно, насколько удобно отлавливать такую подлянку.

Так что даже хорошо настроенный и долгое время работающий сервис вполне может выкинуть подобное.
Ну а поскольку бэкап пишется в бэкап-контейнеры, то узнать о случившемся обычно можно двумя путями: либо глубокой раскуркой мудотнейше организованного евент-лога, либо заглянув внутрь бэкап-контейнера и внимательно сверив даты.

Кстати, если такое вовремя не обнаружить, то в час "Ч" никакой вазелин не спасет.

Использование: Выполнить чудо-скрипт на сервере, узнать, какие индексы работают наименее эффективно (точнее, наиболее редко включаются в работу) и внимательно на них посмотреть, после чего сделать обслуживание баз. Не забыть при этом о том, что даже редко используемый индекс может быть важен для нормального функционирования системы в целом =) Естественно, делать операции с индексами не в середине рабочего дня и обязательно забэкапившись.

/*
SQL script to grab the worst performing indexes
in the whole server
*/
SELECT
  t.TABLE_SCHEMA AS `db`
 , t.TABLE_NAME AS `table`
 , s.INDEX_NAME AS `inde name`
 , s.COLUMN_NAME AS `field name`
 , s.SEQ_IN_INDEX `seq in index`
 , s2.max_columns AS `# cols`
 , s.CARDINALITY AS `card`
 , t.TABLE_ROWS AS `est rows`
 , ROUND(((s.CARDINALITY / IFNULL(t.TABLE_ROWS, 0.01)) * 100), 2) AS `sel %`
FROM INFORMATION_SCHEMA.STATISTICS s
 INNER JOIN INFORMATION_SCHEMA.TABLES t
  ON s.TABLE_SCHEMA = t.TABLE_SCHEMA
  AND s.TABLE_NAME = t.TABLE_NAME
 INNER JOIN (
  SELECT
     TABLE_SCHEMA
   , TABLE_NAME
   , INDEX_NAME
   , MAX(SEQ_IN_INDEX) AS max_columns
  FROM INFORMATION_SCHEMA.STATISTICS
  WHERE TABLE_SCHEMA != 'mysql'
  GROUP BY TABLE_SCHEMA, TABLE_NAME, INDEX_NAME
 ) AS s2
 ON s.TABLE_SCHEMA = s2.TABLE_SCHEMA
 AND s.TABLE_NAME = s2.TABLE_NAME
 AND s.INDEX_NAME = s2.INDEX_NAME
WHERE t.TABLE_SCHEMA != 'mysql'  /* Filter out the mysql system DB */
AND t.TABLE_ROWS > 10 /* Only tables with some rows */
AND s.CARDINALITY IS NOT NULL /* Need at least one non-NULL value in the field */
AND (s.CARDINALITY / IFNULL(t.TABLE_ROWS, 0.01)) < 1.00
/* Selectivity < 1.0 b/c unique indexes are perfect anyway */
ORDER BY `sel %`, s.TABLE_SCHEMA, s.TABLE_NAME
/* Switch to `sel %` DESC for best non-unique indexes */
LIMIT 10;

Скопипиздил отсюда: http://pastebin.com/f6b1c381c, дабы не потерялось.

и снова M$ SQL Server

Posted: 2007-09-22 in IT, Software
Метки:,

То, что бэкап БД надо хотя бы потенциально уметь делать в открытом, стандартном формате (как скажем mysqldump), в МС еще не сообразили.

То есть функция BACKUP DATABASE конечно есть, и SQL Server Agent даже периодически ее выполняет, но к бэкапу лично у меня есть ряд претензий :
— Бэкап без сжатия. Посему для хранения нескольких хронологических копий их приходится паковать. rar сжимает бэкап-контейнер с базами MSSQL в 10 раз. Не шутка. Т.е. бэкап весом в 5 Гб зажимается в ~ 500 Мб-архив.
— Бэкап делается в кривейшем бинарном формате, причем в каждой версии он меняется. У 7.0 — один формат, у 2000 — другой, у 2005 — третий. Посему восстановить старый бэкап на более новой версии сервера — без проблем, а наоборот — никак. И если наши сервера изолированы (Linked Server не сделать, DTS тоже не применить), то перенос БД на старую версию сервера превращается в почти нерешаемую проблему. Причем БД очень старая, еще с Compatibility Level 7.0 (так надо). Как сделать ТЕКСТОВЫЙ SQL-дамп БД встроенными средствами — непонятно (имеется в виду не только структура, но и данные).
С 7.0 на 2000, с 2000 на 2005 — переезд абсолютно беспроблемный.
Но сделать оффлайн-перенос с 2005 на 2000 — это пиздец.

Задача, решаемая в MySQL за несколько минут, здесь превращается в нетривиальную еблю.

M$ SQL старой версии

Posted: 2007-09-22 in IT, Software
Метки:,

Потихоньку пришел к выводу, что практически все серверастое ПО от M$ — просто ужасное. Более-менее сносен только MS SQL 2000/2005. SQL Server 7.0 — срань редкостная, а что было в 6.5 и ранее — страшно даже подумать.

Довелось тут поковыряться в M$ SQL Server 7.0 . Концепция, когда бэкап можно снять без проблем, но восстановить его (на этой же машине, на соседнюю базу) — никак, просто убила. Пишет, что вы должны быть залогинены как sa или входить в группу System Administrators. Проверяем настройки коннекта и секцию Security — правильно, логинимся мы как sa, и пользователь sa и вправду входит в группу System Administrators, те типа все должно быть пучком. А вот хуй вам.
Снять бэкап, управлять пользователями, создавать БД, менять владельцев и тд — ради бога, но восстановиться из только что снятого бэкапа — ни-ни.

M$ SQL Server 2005

Posted: 2007-04-18 in IT, Software
Метки:,

-- msg_table

id (int)      msg_text (varchar[50])     msg_enable (bit)
----------    ------------------------   -----------------
1             Сообщение 1                1
2             Сообщение 2                0
3             Сообщение 3                1

Как Вы думаете, что вернет такой запрос:

SELECT * FROM msg_table WHERE msg_enable = — 1 ?

Ответ — в продолжении… …

(далее…)