Мне тут сообщили, что оказывается выборы в США были очень честными, местные суды нарушений никаких не нашли, а всe, кто сомневается — протрампистские ватники реднеки и злобные попиратели светлой демократии. То, что в светоче демократии попутно зобанели Трампа во всех соцсетях, а соцсеть Parler вообще выперли с облачной платформы Amazon AWS — ну так то тревожный сигнал к импортозамещению и осознанию важности децентрализации шаловливые похождения блудливой невидимой руки свободного рынка.
А теперь к сути.
(далее…)
Записи с меткой «DBMS»
Как рулить выборами в США, зная только SQL
Posted: 2021-01-31 in Приколы, IT, SecurityМетки:DBMS, Security
Три года назад я уже писал заметку, как можно обрабатывать большие выгрузки данных с помощью sed.
Недавно у меня возникла схожая задача: подготавливать файлы с тарифными планами для телефонной станции. Выгрузки эти довольно громоздкие, и вручную их обрабатывать слишком уж долго. Проблема в том, что присылают тарифы обычно в виде XLS-файла с кучей полей, с русскозыячными названиями направлений, тогда как телефонной станции нужен csv-файл, содержащий названия направлений транслитом, точные наименования полей в заголовке и ряд требований к разделителям в итоговом csv-файле.
(далее…)
ISP, биллинг, БД на 20 Гб и практически не работающие внутренние отчеты. Точнее работающие, но очень уж долго. Страшно ? Нет ?! Ну ладно, читаем дальше. …
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 — к прочтению обязательно.
Итак, есть такая задача — перегрузить данные между разными базами данных. Причем совсем разными. Например, из DBF в MySQL. Или из древнего как говно мамонта Paradox (и совершенно уёбищно кривого) в MSSQL. Или из Cronos в PostgreSQL.
(далее…)
Понадобилось тут создать тестовую базу на основе рабочей, восстановив её из ночного бэкапа. Восстановил первый раз — нет нужных данных. Я в шоке. Второй раз. Бля, наверно не выспался. Третий раз. Ну нет, и хоть тресни… Восстановил копирование рабочей, ОК. Полез разбираться, чего за нахер, почему в бэкапе нет нужных данных — и весьма конкретно охуел.
Блджад, перестал делаться бэкап у 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, дабы не потерялось.
То, что бэкап БД надо хотя бы потенциально уметь делать в открытом, стандартном формате (как скажем 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$ — просто ужасное. Более-менее сносен только MS SQL 2000/2005. SQL Server 7.0 — срань редкостная, а что было в 6.5 и ранее — страшно даже подумать.
Довелось тут поковыряться в M$ SQL Server 7.0 . Концепция, когда бэкап можно снять без проблем, но восстановить его (на этой же машине, на соседнюю базу) — никак, просто убила. Пишет, что вы должны быть залогинены как sa или входить в группу System Administrators. Проверяем настройки коннекта и секцию Security — правильно, логинимся мы как sa, и пользователь sa и вправду входит в группу System Administrators, те типа все должно быть пучком. А вот хуй вам.
Снять бэкап, управлять пользователями, создавать БД, менять владельцев и тд — ради бога, но восстановиться из только что снятого бэкапа — ни-ни.
-- 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 ?
Ответ — в продолжении… …
Amin 's Blog 