Любая нештатная ситуация сначала возникает первый раз. Например, скорость мониторинга могла не успеть за метрикой или создание такой ситуации самой системой мониторинга. Но больше вероятность человеческого фактора, в том числе из лучших побуждений, например при невозможности воспроизвести ошибку на тесте приходиться рисковать на бою - сам так делал :)
Япония - работает, сильно упрощая процесс перевода. Потому что перекинуть деньги иным способом - это обязательный поход в Банк по предварительной записи с доказательными бумажками и 2-3 недели на сам перевод, у Примсоц чуть быстрее в пару банков.
Идея класс! Но, как пользователь со стажем, задам вопрос - колебания монитора на столь длинном рычаге при движении как-то решены? При долгом сидении, даже в сверхудобном положении,что-то затекает и организм начинает это компенсировать - мы меняем положение, трясем ногой и пр. Просто при работе с клавиатурой есть колебания весьма монолитного стола. Я был вынужден был заменить кронштейн для монитора, который крепился к столу, на настенный вариант. В данной конструкции, как я вижу, колебания будут напрямую передаваться на монитор. Какой был кошмар в свое время из-за колебания решетки на тринитронах...
Как погруженный в тему - не всегда можно предвидеть. Имея весьма нескромный опыт в кровавом энтерпрайзе и построив эшелонированную оборону от разработки до деплоя на прод, несколько раз ловил epic fail.
В качестве примера - была задача по ограничению доступной инфы на экране признаку VIP. VIP'ов было пара сотен, что на фоне миллионов клиентов даже в пределы погрешности не укладывалось. Задачку примитивная, скинули джуну, по феншую фичу даже протестировали на паре офисов и забыли до отмашки заказчиком. Через пару месяцев вместе с глобальным обновлением включили в релиз - как крыжик в настройках...
Джун, ему простительно, реализовал прекрасно: на каждый (ты вдруг VIP'ом стал внезапно) got/lost focus элемента формы проверка через select * from vip, дальше поиск по массиву уже на клиенте...
В форме, центральной, было несколько десятков закладок, пара сотен статических и, в зависимости от, еще минимум сотня динамических элементов. А в момент открытия формы, как мы потом узнали, каждый (!) элемент генерил эти 2 события. И в понедельник утром > 5 тыс. ничего не подозревающих пользователей пришли на работу. И не могли открыть форму, приложение "висело", они его срубали и открывали заново. Восточные регионы успели, а следующие часовые пояса уже нет, что внесло свои коррективы в понимание проблемы. Мы докидывали сервера приложений, которые принимались переваривать все новые сессии пользователей, а старые никуда не девались, пока не дорабатывали до конца или мы не перегружали сервак. Между БД и серверами приложений гнался немеренный траффик. К БД было подключено несколько десятков и других приложений, и там тоже началась деградация.
Тем, кто не очень в теме БД, простой select из базы в таком виде грубо: declare stmt/open cursor/fetch 200+ rows/close cursor, каждое действие это несколько пакетов, каждый фетч страница в 4Кб, умноженное на число строк в таблице - 200+ и умноженное на 2*300 раз за контрол на форме на каждого пользователя=5000 и каждую зависшую сессию - умножить еще на 2. И все это в единицу времени. "Ватага зайцев мочит льва."
Мы ddos-или собственную инфру. И самое главное, не понимали причину, поднимали новые сервера => создавали все новую нагрузку, положили сеть. Снять дампы или включить детальный мониторинг было нереально. А причину, без инструмента и исходных данных, искали, как вы понимаете, теоретически, в последних-предпоследних-предпредпоследних изменениях. Судорожные откаты к результату не приводили, управлять пользователям мы в тот момент не умели. А про крыж в настройках никто не подумал, потому что дата файла с этими настройками из репозитория (феншуй епрст!) оказалась, как можно догадаться, 2-х месячной давности.
Как DBA отвечу:
И разработка и ревью изменений БД - было. И на деве, тесте, предпроде и, частично на проде, были настроены мониторинги - кривые запросы к БД отлавливались автоматом по целому сету условий. Но на экранах радаров эту мелочь не заметили, от пары юзверей пусть даже несколько тысяч запросов, из кеша в пару тестовых записей, которые относительно нескольких сотен транзакций в секунду, не попали в top-100 ни по одному показателю.
Графики нагрузки на продуктивные БД имели историю, анализ, с указанием причин изменений ключевых показателей, объяснения динамики и "красные линии", с историчностью в несколько лет и разбирались на еженедельной основе вместе с разрабами. И с точки зрения написанного кода, и бизнес-показателей, внедрения новых фич и тп. Не говоря уже про даш-борды и алерты для группы онлайн-мониторинга 24х7.
"Можно придумать защиту от дурака, но только неизобретательного" ИТ-шная мудрость
Конечно, нет. Неужели можно предположить, что перед тем, как добраться до расширенных настроек биоса, старый админ не проверил все порты, режимы/настройки системы, не перелопатил реестр и тп :) Дошел до инженеров вендора - увы.
А про виртуальные карты месье не слышал и копирование номера из банковского приложения? И чем плохи менеджеры паролей, которые не хранят данные неизвестно где "в облаке" и доступа в сеть не имеют?
Боль! Года 3-4 назад победил, тоже был тот еще квест, через расширенные настройки биоса и правкой реестра.
Но осталась одна нерешенная - USB порт не отключается никак, кроме как при shutdown. А на это было завязан сетап с отключением питания периферии (подставки/монитора и тп). Максимум достигнутого, порт отключается при отсутствии внешнего питания. И это "by design".
Институт Проблем Управления (ИПУ) был одним из тех, кто считал зарплату для других, и гуляла байка. Привозили списки особые люди с чемоданчиками на браслетах, и, как правило, накануне 5-го и 20-го, сразу все. Множество теток-машинисток забивало все это на УПД, потом программеры переносили на ЭВМ. Один из сотрудников лабы подготовки данных попросил одних таких привести в следующий раз не распечатку, которую сразу было видно, а записать на носитель - хотя бы перфорленту, если магнитных лент нет. И в следующий раз привезли. Сколько потребовалось солдат, чтобы переписать текст на перфоленту никто не знает, а того, кто это увидел, потом долго отпаивали спиртом.
Шпаргалка вещь хорошая, но многим из поколения ЕГЭ нужны готовые примеры. Могу порекомендовать по SQL книжку с хорошими примерами, проверенную веками :), http://db2-sql-cookbook.org/, особенности синтаксиса db2 можно спокойно пропустить.
Т.е. через 100 мс откат по таймауту? Или все же Deadlock_timeout — ну если читать как написано, должен лишь означать период для запуска процесса проверки и разрешения deadlock'ов? Процесс этот весьма затратный по ресурсам при большом числе соединений и транзакций, только на период стабилизации выставляем его в минимум. И deadlock не может развязаться сам по себе — менеджер принудительно откатывает одну из блокирующих транзакций. И как раз чтобы понять, как транзакции сумели войти в клинч, нужна история во времени со всеми стейтментами и, по созданным блокировкам, снапшот на момент обнаружения.
Я не понимаю как можно «снимать состояние блокировок в базе» для oltp-системы, где locklist в десятки тысяч записей, который меняется с каждым стейтмент'ом…
тема требует объяснений очень издалека. Классические БД автоматизировали ручной процесс и мы с вами пользуемся «аналоговыми» базами в повседневной жизни. Попытайтесь сначала представить процесс не автоматизированным — как норвеги, например, проверили IP на голубях. В качестве примера те же носки — купил упаковку в 10 пар в m&s — они черные, положил в ящик = таблица, единственный аттрибут — цвет. Выборка будет — жена, дай пару черного цвета — select… where color=black… fetch 2. Да? Или по номеру? Тут еще подолью масла в огонь, любимый всеми STATUS — «and status=0». Это значит, что чистые и грязные носки у вас лежат в одном ящике и команда жене расшириться на предикат «понюхай каждый»…
Если у Вас все носки пронумерованы, тут крыть нечем. Это особый случай — для этого обычно применяются key value db.
Изначальный посыл статьи — боль сопровождения, как последствия неудачного проектирования.
А как все просто в мире кровавого энтерпрайза -для deadlock/locktimeout события с полной хистори валятся в файл, для нужд мониторинга счетчики автоматом собираются и на уровне менеджера, базы и отдельного коннекта, для расследования — create event monitor for locking и вся картина есть… А ловить в онлайне на oltp базе прода с тысячами транзакций в сек — я не представляю. У нас lock_timeout большинства приложений 1 сек., у привилегированных 5. Конечно, далеко не все просто — бывает сложно разобраться, когда встречаются больше 2 транзакций. Плюс нужно понимать, не было ли эскалаций, с каким уровнем изоляции выполнялось и тд. А если это для olapa — там, обычно, проще по стейтментам пройтись.
Реализация счетчика для БД, в конкурентной среде, задача нетривиальная. При реализация с полной блокировкой возможен только один поток. Вынужденно каждому соединению сервер выделяет блок значений от сиквенса, в результате счетчик перестает быть счетчиком как таковым. Последовательность получения значений и реальный порядок попадания записей в БД нарушается, образуются дыры. При кластерной конфигурации наступает катастрофа, т.к. мастером по сиквенсу может выступать только один сервер и другие вынуждены обращаться к нему — при операциях даже в 1с сетевые задержки уже существенны. Представьте слегка нагруженную oltp базу с 1000 коннектов и 20 тыс транзакций (не операций) в сек. и хотя бы 0.01% из них вдруг замедлиться на 100 ms.
Все вышеописанное, как и статья, относится к промышленным системам. Хотя проблема может выстрелить и при относительно примитивном сценарии — система А передает события с ID типа счетчик в систему Б, система Б по данному ID обеспечивает идемпотентность, счетчик рестартовали…
При этом никто не будет бить по голове разраба, если он использует сиквенс для справочника в сотню строк, который дополняется раз неделю. Хотя и тут возможны проблемы — когда у вас несколько сред, например, тестирования…
Могут. Но «носок номер 5 и 12 составляют пару» как-то в жизни не используем…
А как только разработчик использует rowid — он не понимает БД от слова совсем.
А типовая ситуация, когда две базы связаны через ключи-счетчики и одну откатили — и начались танцы с бубном по синхронизации.
В DB2 с доисторических времен для генерации ключей рекомендовалось generate_unique() основанное на времени и номера сервера для кластерных конфигураций. При этом метка времени не является бессмысленным суррогатом и может, например, ограничивать выборку как предикат или использоваться для шардирования таблицы.
При проектировании БД нужно придерживаться естественных ключей.
Эх… Первые 486 dx33 в России прошли через мои руки… У них еще биос настраивать нужно было регистрами, ох и квест был!
Для ностальгии по 486: да, и DX50 у меня был, awe32 — супер, после adlib'a. А еще не хватает кэш-контроллера tekram'a, которому можно было перепаять кварц и поправить биос :). А для тех, кто в теме — платы periscope, модема (от 2400 нифига.bis), арвида, крутой мыши sicos… Спасибо! 2:5020/1.21
Любая нештатная ситуация сначала возникает первый раз. Например, скорость мониторинга могла не успеть за метрикой или создание такой ситуации самой системой мониторинга. Но больше вероятность человеческого фактора, в том числе из лучших побуждений, например при невозможности воспроизвести ошибку на тесте приходиться рисковать на бою - сам так делал :)
Япония - работает, сильно упрощая процесс перевода. Потому что перекинуть деньги иным способом - это обязательный поход в Банк по предварительной записи с доказательными бумажками и 2-3 недели на сам перевод, у Примсоц чуть быстрее в пару банков.
Идея класс! Но, как пользователь со стажем, задам вопрос - колебания монитора на столь длинном рычаге при движении как-то решены? При долгом сидении, даже в сверхудобном положении,что-то затекает и организм начинает это компенсировать - мы меняем положение, трясем ногой и пр. Просто при работе с клавиатурой есть колебания весьма монолитного стола. Я был вынужден был заменить кронштейн для монитора, который крепился к столу, на настенный вариант. В данной конструкции, как я вижу, колебания будут напрямую передаваться на монитор. Какой был кошмар в свое время из-за колебания решетки на тринитронах...
" в команде нет DBA"
Зацепило.
Как погруженный в тему - не всегда можно предвидеть. Имея весьма нескромный опыт в кровавом энтерпрайзе и построив эшелонированную оборону от разработки до деплоя на прод, несколько раз ловил epic fail.
В качестве примера - была задача по ограничению доступной инфы на экране признаку VIP. VIP'ов было пара сотен, что на фоне миллионов клиентов даже в пределы погрешности не укладывалось. Задачку примитивная, скинули джуну, по феншую фичу даже протестировали на паре офисов и забыли до отмашки заказчиком. Через пару месяцев вместе с глобальным обновлением включили в релиз - как крыжик в настройках...
Джун, ему простительно, реализовал прекрасно: на каждый (ты вдруг VIP'ом стал внезапно) got/lost focus элемента формы проверка через select * from vip, дальше поиск по массиву уже на клиенте...
В форме, центральной, было несколько десятков закладок, пара сотен статических и, в зависимости от, еще минимум сотня динамических элементов. А в момент открытия формы, как мы потом узнали, каждый (!) элемент генерил эти 2 события. И в понедельник утром > 5 тыс. ничего не подозревающих пользователей пришли на работу. И не могли открыть форму, приложение "висело", они его срубали и открывали заново. Восточные регионы успели, а следующие часовые пояса уже нет, что внесло свои коррективы в понимание проблемы. Мы докидывали сервера приложений, которые принимались переваривать все новые сессии пользователей, а старые никуда не девались, пока не дорабатывали до конца или мы не перегружали сервак. Между БД и серверами приложений гнался немеренный траффик. К БД было подключено несколько десятков и других приложений, и там тоже началась деградация.
Тем, кто не очень в теме БД, простой select из базы в таком виде грубо: declare stmt/open cursor/fetch 200+ rows/close cursor, каждое действие это несколько пакетов, каждый фетч страница в 4Кб, умноженное на число строк в таблице - 200+ и умноженное на 2*300 раз за контрол на форме на каждого пользователя=5000 и каждую зависшую сессию - умножить еще на 2. И все это в единицу времени. "Ватага зайцев мочит льва."
Мы ddos-или собственную инфру. И самое главное, не понимали причину, поднимали новые сервера => создавали все новую нагрузку, положили сеть. Снять дампы или включить детальный мониторинг было нереально. А причину, без инструмента и исходных данных, искали, как вы понимаете, теоретически, в последних-предпоследних-предпредпоследних изменениях. Судорожные откаты к результату не приводили, управлять пользователям мы в тот момент не умели. А про крыж в настройках никто не подумал, потому что дата файла с этими настройками из репозитория (феншуй епрст!) оказалась, как можно догадаться, 2-х месячной давности.
Как DBA отвечу:
И разработка и ревью изменений БД - было. И на деве, тесте, предпроде и, частично на проде, были настроены мониторинги - кривые запросы к БД отлавливались автоматом по целому сету условий. Но на экранах радаров эту мелочь не заметили, от пары юзверей пусть даже несколько тысяч запросов, из кеша в пару тестовых записей, которые относительно нескольких сотен транзакций в секунду, не попали в top-100 ни по одному показателю.
Графики нагрузки на продуктивные БД имели историю, анализ, с указанием причин изменений ключевых показателей, объяснения динамики и "красные линии", с историчностью в несколько лет и разбирались на еженедельной основе вместе с разрабами. И с точки зрения написанного кода, и бизнес-показателей, внедрения новых фич и тп. Не говоря уже про даш-борды и алерты для группы онлайн-мониторинга 24х7.
"Можно придумать защиту от дурака, но только неизобретательного" ИТ-шная мудрость
Конечно, нет. Неужели можно предположить, что перед тем, как добраться до расширенных настроек биоса, старый админ не проверил все порты, режимы/настройки системы, не перелопатил реестр и тп :) Дошел до инженеров вендора - увы.
А про виртуальные карты месье не слышал и копирование номера из банковского приложения? И чем плохи менеджеры паролей, которые не хранят данные неизвестно где "в облаке" и доступа в сеть не имеют?
Боль! Года 3-4 назад победил, тоже был тот еще квест, через расширенные настройки биоса и правкой реестра.
Но осталась одна нерешенная - USB порт не отключается никак, кроме как при shutdown. А на это было завязан сетап с отключением питания периферии (подставки/монитора и тп). Максимум достигнутого, порт отключается при отсутствии внешнего питания. И это "by design".
Институт Проблем Управления (ИПУ) был одним из тех, кто считал зарплату для других, и гуляла байка. Привозили списки особые люди с чемоданчиками на браслетах, и, как правило, накануне 5-го и 20-го, сразу все. Множество теток-машинисток забивало все это на УПД, потом программеры переносили на ЭВМ. Один из сотрудников лабы подготовки данных попросил одних таких привести в следующий раз не распечатку, которую сразу было видно, а записать на носитель - хотя бы перфорленту, если магнитных лент нет. И в следующий раз привезли. Сколько потребовалось солдат, чтобы переписать текст на перфоленту никто не знает, а того, кто это увидел, потом долго отпаивали спиртом.
Шпаргалка вещь хорошая, но многим из поколения ЕГЭ нужны готовые примеры. Могу порекомендовать по SQL книжку с хорошими примерами, проверенную веками :), http://db2-sql-cookbook.org/, особенности синтаксиса db2 можно спокойно пропустить.
А Pirates! от гения Сида, какую карту мы рисовали. Да и вообще шедевры от Microprose — F19,Civ, Covert Action, Darklands, MoO, MoM, X-Com!
Warlords. «за два хода не дойду» — эту фразу разбуженного приятеля в ответ на предложение пойти на кухню я не забуду :)
А EoB? А Sierra — King/Police/Space Quest и Larry, те, ламповые — cut erotic sculpture?
Пойду сушить клавиатуру залитую ностальгией.
Я не понимаю как можно «снимать состояние блокировок в базе» для oltp-системы, где locklist в десятки тысяч записей, который меняется с каждым стейтмент'ом…
Если у Вас все носки пронумерованы, тут крыть нечем. Это особый случай — для этого обычно применяются key value db.
Изначальный посыл статьи — боль сопровождения, как последствия неудачного проектирования.
Вы совершенно не понимаете, что такое БД.
2. Программисты привыкли к массивам и меткам.
Реализация счетчика для БД, в конкурентной среде, задача нетривиальная. При реализация с полной блокировкой возможен только один поток. Вынужденно каждому соединению сервер выделяет блок значений от сиквенса, в результате счетчик перестает быть счетчиком как таковым. Последовательность получения значений и реальный порядок попадания записей в БД нарушается, образуются дыры. При кластерной конфигурации наступает катастрофа, т.к. мастером по сиквенсу может выступать только один сервер и другие вынуждены обращаться к нему — при операциях даже в 1с сетевые задержки уже существенны. Представьте слегка нагруженную oltp базу с 1000 коннектов и 20 тыс транзакций (не операций) в сек. и хотя бы 0.01% из них вдруг замедлиться на 100 ms.
Все вышеописанное, как и статья, относится к промышленным системам. Хотя проблема может выстрелить и при относительно примитивном сценарии — система А передает события с ID типа счетчик в систему Б, система Б по данному ID обеспечивает идемпотентность, счетчик рестартовали…
При этом никто не будет бить по голове разраба, если он использует сиквенс для справочника в сотню строк, который дополняется раз неделю. Хотя и тут возможны проблемы — когда у вас несколько сред, например, тестирования…
А как только разработчик использует rowid — он не понимает БД от слова совсем.
В DB2 с доисторических времен для генерации ключей рекомендовалось generate_unique() основанное на времени и номера сервера для кластерных конфигураций. При этом метка времени не является бессмысленным суррогатом и может, например, ограничивать выборку как предикат или использоваться для шардирования таблицы.
При проектировании БД нужно придерживаться естественных ключей.
Для ностальгии по 486: да, и DX50 у меня был, awe32 — супер, после adlib'a. А еще не хватает кэш-контроллера tekram'a, которому можно было перепаять кварц и поправить биос :). А для тех, кто в теме — платы periscope, модема (от 2400 нифига.bis), арвида, крутой мыши sicos… Спасибо! 2:5020/1.21