Администрирование баз данных *

Наверное, каждый, кто работает с SQL Server оказывался, или ещё окажется, в такой ситуации: вечер пятницы, ты уже мысленно готов отдыхать и тут начинают прилетать уведомления о высокой нагрузке на CPU твоего SQL Server, телефон начинает звонить и в системе мониторинга ты видишь картинку как на КДПВ.

И, с одной стороны, в этом может не быть особой проблемы - да, серверу тяжело, да, это неприятно, но ведь, господи, ну сформируется ваш отчёт не за 15, а за 45 секунд - делов-то, вы же видите - вас много, а сервер один, нужно просто немножко подождать. Но что, если при всём при этом, есть какие-то бизнес-процессы, которые не могут ждать? Что если при такой нагрузке продажа товара становится настолько медленной, что покупатели отказываются от покупки?

Вот было бы здорово, если бы можно было разделить процессы/пользователей и сказать SQL Server - вот это вот очень важные ребята, их запросы должны выполняться в первую очередь. А вот эти - они, конечно, тоже важные, но они могут подождать подольше. А вот это вот - это вообще запросы от системы мониторинга, которые давно уже надо переписать, и на них вообще можно не обращать внимания, пока мы тут занимаемся важными вещами.

• Автоматическое журналирование компиляций
• Как быть, если хочется сделать вьюшку с параметрами
• Использование динамической статистики в запросах
• Как сохранить план запроса при вставке данных через database link
• Запуск процедур в параллельных сессиях
• Протягивание остатков
• Объединение нескольких историй в одну
• Нормалайзер
• Визуализация в формате SVG
• Приложение поиска по метаданным Oracle

Задача 2

Введение

Начало — Alert

• Крайне важно разработать схему несмотря на то, что в MongoDB она необязательна.
• Аналогично, индексы должны соответствовать вашей схеме и шаблонами доступа.
• Избегайте использования больших объектов и больших массивов.
• Будьте осторожны с настройками MongoDB, особенно если речь идет о безопасности и надежности.
• В MongoDB нет оптимизатора запросов, поэтому вы должны быть осторожны при выполнении операций запроса.

OFFSET start { ROW | ROWS }
FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } { ONLY | WITH TIES }

Здравствуйте.

Решил поделится своей находкой — плодом раздумий, проб и ошибок.
По большому счёту: это никакая не находка, конечно же — всё это должно быть давно известно, тем кто занимается прикладной стат-обработкой данных и оптимизацией каких либо систем, не обязательно именно СУБД.
И: да знают, пишут занятные статьи по своим ресерчам, пример (UPD.: в комментариях указали на очень интересный проект: ottertune )
С другой стороны: навскидку не усматриваю широкого упоминания, распространения такого подхода, в интернете, среди ит-специалистов, ДБА.

Итак, к сути.

В этой статье мы научимся шифровать бэкапы, загружать их в S3-совместимое хранилище (вместо второго сервера-репозитория), восстанавливаться на чистый кластер и, наконец, восстанавливаться на определенный момент времени (point in time recovery, PITR).

Вы только что установили PostgreSQL и запустили ваш первый кластер, создали несколько таблиц, загрузили данные, и даже немного подкрутили конфигурацию PostgreSQL для улучшения производительности. Теперь вы думаете о том, как сделать ваш кластер высокодоступным. К сожалению, PostgreSQL не умеет сам выполнять автоматическое переключение при недоступности мастера, но, к счастью для нас, этого можно достичь с помощью сторонних утилит. Задача ясна, и вы начинаете изучать преимущества и недостатки всех утилит, чтобы выбрать лучшую. И… вы уже на неправильном пути, потому что в первую очередь вы должны определиться со значениями SLA, RTO и RPO. В этом докладе я планирую рассказать о ряде ошибок, которые допускают администраторы баз данных при настройке и эксплуатации высокодоступного кластера Постгреса с автоматическим переключением.

С транскриптом первой части, посвященной типовым проблемам производительности запросов и их решениям, можно ознакомиться в статье «Рецепты для хворающих SQL-запросов».