Программа мониторинга бд что это
20 бесплатных утилит и 89 скриптов для мониторинга и управления базами данных
Ты сидишь — база растёт, идёшь — база растёт, спишь, ешь или делаешь ещё много всего, а база всё растёт и растёт. Кто-то очень умный сказал, что единственное, что в нашей жизни постоянно — это изменения. Главное — правильно на них реагировать. Любая нештатная ситуация с базой данных происходит именно из-за таких изменений. К сожалению, не всегда есть возможность вложиться в расшитую золотом и усыпанную драгоценными камнями в 60 карат промышленную систему мониторинга. И это заставляет прибегнуть к бесплатным или условно-бесплатным решениям. В статье я собрал 20 бесплатных утилит от компании IDERA (и не только), которые могут некисло помочь закрыть некоторые вопросы с мониторингом и управлением MS SQL, MySQL и Oracle. Поехали!
#1 SQL Check
Утилита позволяет контролировать производительность SQL сервера. Не требуется установка агента на сервере БД и инжекция специальных объектов непосредственно в саму БД. 
#2 SQL Fragmentation Analyzer
Утилита помогает находить фрагментированные таблицы и предупреждает, когда нужно делать дефрагментацию.
#3 SQL XEvent Profiler
Просмотр сессий и выполняемых SQL-выражений. Из дополнительных плюшек — группировка, сортировка и экспорт событий.
#4 SQL Heat Map
Визуальное представление использования дискового пространства в разрезе всех таблиц в БД. Поможет управлять мощностями и сделать прогноз ресурсов, которые могут потребоваться в будущем. Быстро определит таблицы и индексы, которые требуют выделения дополнительного дискового пространства.
#5 SQL Page Viewer
Удобный просмотр и управление объектами и событиями БД.
#6 SQL Update Statistics
Определение устаревшей статистики по таблицам и индексам, просмотр и изменения опций статистики.
#7 SQL Statistics Aggregator
Агрегация статистики по IO для идентификации проблемных таблиц, корреляция дисковой активности с планами выполнения.
#8 SQL Hekaton Memory Check
Мониторинг влияния утилизации памяти конкретными таблицами БД.
#9 SQL Instance Check
Сбор данных и инвентаризация БД, проверка актуальности установленных обновлений на БД.
#10 SQL BI Check
Мониторинг в реальном времени для SSAS, просмотр и аналитика потребления CPU, памяти и диска.
#11 SQL Query Store Optimizer
Повышение производительности сервиса Query Store.
#12 MySQL Query Explorer
Мониторинг топа ресурсоёмких запросов MySQL, просмотр статистики выполнения запросов для проведения тюнинга БД.
#13 SQL Backup Status Reporter
Определение баз данных, не имеющих бэкапа, просмотр истории бэкапов.
#14 SQL Integrity Check
Умеет запускать CHECKDB для SQL базы данных по запросу.
#15 SQL Job Manager
Просмотр текущих и прошлых джобов.
#16 PowerShell Plus
Специальное IDE для работы с PowerShell скриптами.
#17 Rapid Database Extractor
Управление источниками данных для SQL и Oracle, манипуляции с объектами БД, выполнение SQL-запросов для извлечения данных.
#18 SQL Permissions Extractor
Умеет генерировать T-SQL скрипты для копирования разрешений пользователя.
#19 SQL Column Search
Поиск и экспорт чувствительных данных (номера кредитных карт и прочие персональные данные).
#20 DBATools
Модуль миграции и администрирования для SQL Server на Powershell.
#00 PowerShell Scripts for SQL Server
А вот и они! 89 скриптов для управления SQL сервером, скрипты для анализа, интеграции, отчетности.
Настройка мониторинга состояния базы данных
Успешные и динамично развивающиеся стартапы часто достигают точки, когда проблемы с базой данных уже есть, а отдельного человека для их решения еще нет. Впрочем, и не всем он нужен. Сервис мониторинга ХостТрекер предлагает возможность автоматически следить за ключевыми показателями жизнедеятельности базы без необходимости каждый день лезть на сервера вручную. Ниже мы расскажем, как ловить популярные ошибки, защититься от внезапного переполнения базы, быть уверенным в том, что всегда есть свежий и успешный бэкап ну и еще по мелочи.
Как это работает
В силу специфики сервиса, в первую очередь решаются задачи по мониторингу баз сайтов, что вместе с другими способами проверок может дать подробную диагностику проблем сайтов. Но вообще можно использовать этот инструмент для любых баз, к которым есть доступ из сети.
Для начала, нужно подключиться к базе. Настоятельно рекомендуем для безопасности создать отдельную учетную запись и дать ей права только на чтение и только на те таблицы, которые планируете проверять. Далее, выбираете интервал проверки — от 10 минут до раза в сутки. И вводите запрос, который планируете регулярно исполнять, составив его таким образом, чтобы результат, который Вам необходимо проверять, представлял из себя одно из двух:
Далее — самое интересное. Можно настроить проверку результатов. Например, смотреть, не изменилось ли определенное значение с помощью условий «равно — не равно» (здесь как раз можно и GUID проверять, и строки). Для числовых значений также дополнительно есть условия больше/меньше или попадает/не попадает ли значение в определенный интервал.
По любому запросу можно настроить оповещения, которые будут приходить по СМС или другим способом, если искомое значение превышено.
При необходимости, добавляем указанные адреса в файрвол.
Популярные применения
Все это настраивается один раз, возвращаться к вопросу приходится лишь в случае возникновения проблем. Самим нужно лишь написать корректный запрос. Впрочем, мы и это попытаемся исправить: ниже можно найти список запросов, которые могут быть особенно полезными при подобном мониторинге. Все — для MS SQL, но большинство запросов несложно конвертируется и для других баз.
Чтобы повысить безопасность, можно создать процедуру, в которую включить эти запросы и дать права на ее исполнение указанному логину. Либо же создать промежуточную таблицу, в которую записывать результаты этих запросов, и уже для нее предоставить права на чтение для Host-tracker.
Информация о последнем успешном бэкапе:
SELECT TOP 1 database_name, backup_size, backup_start_date, backup_finish_date
FROM msdb..backupset bs
ORDER BY backup_set_id DESC
Количество подключений к базе в этот момент:
SELECT COUNT(*) AS connections FROM sys.dm_exec_connections
Время последнего запуска сервера БД, количество ЦПУ и оперативной памяти
SELECT sqlserver_start_time, cpu_count, physical_memory_kb
FROM sys.dm_os_sys_info
Размер файлов и доступное место для текущей базы данных:
Сколько места доступно для текущей базы данных:
SELECT (SUM(unallocated_extent_page_count)*1.0/128) AS [free space in MB]
FROM sys.dm_db_file_space_usage
Сколько места доступно для базы TEMPDB:
SELECT (SUM(unallocated_extent_page_count)*1.0/128) AS [free space in MB]
FROM tempdb.sys.dm_db_file_space_usage
Пишите, если считаете нужным внести в этот список что-то еще. Также, как и всегда — рады вашим пожеланиям и дополнениям.
Программа мониторинга бд что это
Программа мониторинга базы данных и обновления карты
Программа мониторинга базы данных и обновления карт предназначена для обработки и синхронизации пространственных данных, содержащихся на цифровой векторной карте и хранящихся в различных базах данных.
Продукт реализован на русском языке.
Программа мониторинга может выполняться в следующих режимах:
Актуализированные тематические карты могут быть доступны пользователям через ГИС Сервер или GIS WebServer для организации графического интерфейса доступа к базам данных.
С помощью Программы мониторинга базы данных и обновления карт, выполняемой в режиме обновления информации в БД по данным цифровой карты, можно использовать любую ГИС, работающую с картами формата «Панорама», в качестве универсального средства визуального редактирования пространственной информации, хранящейся непосредственно в базе данных.
В программе реализована технология внешнего хранения картографической информации из базы данных в виде отдельной цифровой карты. В отличие от существующих технологий отображения картографических данных непосредственно из базы, представленная реализация позволяет осуществлять прямой доступ к карте без обращения к базе, когда этого не требуется. Карта может быть доступна пользователям в локальной сети, к ней может быть организован доступ для «тонких клиентов», она может быть переслана по электронной почте в виде вложения и т.д. Кроме этого значительно сокращается время отображения картографической информации. Так, например, для карты, содержащей порядка 1000 000 объектов, при отображении непосредственно из базы данных будет затрачено несколько минут, тогда как визуализация этой же карты, хранящейся отдельно, требует несколько секунд. Обновление данных с помощью программы мониторинга может производиться как единовременно по необходимости, так и в автоматическом режиме с заданным интервалом времени. Доступна также функция внешнего управления Программой мониторинга посредством параметризированных запросов, выполняемых из командной строки.
Программа мониторинга базы данных и обновления карты при выполнении операций синхронизации данных в циклическом режиме (по таймеру) может без остановки процесса «подхватывать» файл настроек. Если настройки изменились (например, администратор внес изменения в файл настроек или подменил его), программа автоматически распознает это и применит новые настройки со следующей итерации обновления данных.
Предусмотрена возможность обработки пространственных данных в Базе в двух вариантах:
Настоящая версия программы обеспечивает работу со следующими базами данных:
Имеется возможность подключения к любой базе данных, используя настроенное соединение ODBC (dBase, Paradox, Microsoft Excel, Linter, PostgreSQL и пр.).
Задача размещения пространственной информации в базе данных является актуальной для многих современных систем. Перспективным решением в этом направлении является применение технологии хранения пространственной информации с использованием встроенной ГИС-подсистемы самой СУБД. Такая подсистема позволяет хранить пространственное описание объекта в поле специального типа. Предоставление доступа к таким данным и их обработка осуществляется на базе общепринятых стандартов, утвержденных Open GIS Consortium. Для работы с пространственными базами данных, построенных по указанной технологии, предназначена программа Panorama SpatialDB Service. Программа мониторинга базы данных и обновления карты позволяет обрабатывать метрику объектов, размещаемую в БД в табличном виде.
Программа мониторинга базы данных и обновления карты позволяет:
Сведения об объектах предоставляются базой данных программе мониторинга в виде таблиц или представлений. Предусмотрено наличие трех таких таблиц или представлений:
Таблица метрики предназначена непосредственно для предоставления Программе Мониторинга доступа к пространственной информации обновляемых объектов. Возможны два варианта размещения пространственных данных (координат объектов):
При размещении пространственной информации по объектам в виде таблицы координат точек, поддерживаются системы координат 42 года, WGS84, ПЗ-90.
Примечание
Таблица учета изменений предназначена для регистрации изменений объектов для их отображения на карте. В случае если в настройках программы мониторинга разрешено использование этой таблицы, на карте будут отредактированы только те объекты мониторинга, изменения которых зарегистрированы в таблице изменений.
При работе с пространственными данными в формате Oracle Spatial имеются ограничения:
Для режима выполнения мониторинга в направлении «Карта > База данных» необходимо, чтобы интерфейсные таблицы или представления в базе данных («Таблица описания объекта» и «таблица метрики объекта») были доступны не только на чтение, а еще и на запись.
Автоматизация запуска множества экземпляров программы
Один экземпляр программы мониторинга единовременно может выполнять синхронизацию с картой только одного набора данных и только в одном направлении. Для взаимной актуализации данных из нескольких электронных карт с несколькими наборами данных в одной или нескольких базах данных необходим запуск нескольких экземпляров программы с разными настройками. Количество необходимых экземпляров программы мониторинга равно количеству связок «Карта – Набор данных», выполняемых в одном из направлений мониторинга.
Для автоматизации запуска одновременно нескольких экземпляров Программы мониторинга формируется перечень этих экземпляров с помощью программы Менеджер запуска, включенной в состав программного комплекса. Запуск программ, входящих в данных перечень, может осуществляться как непосредственно из программы Менеджер запуска Программы мониторинга, так и специальной службой из состава программного комплекса Программы мониторинга. Служба выполняет старт экземпляров программ по списку при старте операционной системы, даже если не выполняется вход пользователя в систему.
Добавляемые в список автоматизированного запуска экземпляры Программы мониторинга должны уже быть полностью настроены для подключения к базе данных и карте и для выполнения процесса синхронизации данных между ними. При этом сам исполняемый файл (db2map.exe) может быть один для всех запускаемых экземпляров, а файл настроек и файл журнала работы обязательно должны быть персональными для каждого экземпляра.
Внешний вид Менеджера запуска
Программы мониторинга
Назначение кнопок главного меню
программы Менеджер запуска
Работа в режиме системной службы
Системная служба выполняет старт экземпляров программы по списку при старте операционной системы, даже если не выполняется вход пользователя в систему.
Перечень экземпляров Программы мониторинга БД и обновления карт, подлежащих автоматическому запуску, формируется Менеджером запуска (см. выше).
Управление службой осуществляется из стандартной консоли операционной системы.
Консоль управления системными службами операционной системы
При старте службы, она выполняет запуск всех экземпляров Программы мониторинга согласно перечня, предварительно подготовленного в программе Менеджер запуска Программы мониторинга БД и обновления карт. При остановке службы она рассылает всем запущенным ею экземплярам Программы мониторинга команду на завершение работы, выжидает некоторое время, чтобы экземпляр мог завершить свою работу самостоятельно, после чего принудительно останавливает процесс, в рамках которого выполняется данный экземпляр.
Удаленное отслеживание процесса работы
Каждый экземпляр Программы мониторинга ведет свой собственный журнал работы, который может сохраняться в текстовый файл с заданной периодичностью. Обеспечив удаленный доступ к просмотру таких файлов-протоколов, пользователь получает возможность удаленного отслеживание процесса работы программы. Доступ к журналам работы Программ мониторинга может быть можно организовать как в виде файлового доступа в локальной сети, так и публикацией в сети Интернет, например, с помощью веб-серверов IIS или Apache.
Настройка интервала сохранения файла
протокола работы Программы мониторинга
Удаленный просмотр логов Программы мониторинга
через Интернет с помощью стандартного web-браузера.
4 уровня мониторинга баз данных
Мониторинг баз данных — это комплексная задача, которая включает в себя отслеживание показателей производительности баз данных на различных уровнях: SQL (оптимальности запросов), экземпляр БД, инфраструктура, пользователи. Эти четыре уровня описывают области, которые могут оказать значительное влияние на производительность баз данных.
Уровень SQL-синтаксиса
Не каждый разработчик может сразу написать такой SQL-запрос, который вжух и выполнился. Иногда на это может уйти несколько итераций. Задача мониторинга — выявить такие SQL-запросы и сообщить о них кому следует. Посмотрим, где можно найти корень зла.
Статистика SQL-оптимизатора. Их много для разных БД, есть из чего выбрать. Результаты могут удивить.
Планы выполнения (execution plans). «GPS», который выдаст инструкции о том, как эффективно добраться из точки a в точку b. Иногда путь может напоминать американские горки. Планы выполнения включают ключевую информацию: индексы, связанные с объектами базы данных, и влияние/стоимость каждого шага в выполнении последовательности SQL-запросов.
Маски (wild cards). Это бич некоторых приложений. SELECT * в небольшую таблицу не вызовет значительного снижения производительности. Очевидно, что в больших БД это будет целой проблемой.
Фильтрация. Когда WHERE уже слишком поздно. Чем раньше будет сокращён общий набор данных, тем меньше нагрузка на логические и физические ресурсы.
Преобразования. Преобразование данных из одного типа в другой — дорогая операция. Если тип данных столбца varchar, а вы пытаетесь сравнить значения в этом столбце с целым числом, требуется неявное преобразование. Лучше этого избежать.
Построчная обработка. Лучше обрабатывать наборы, а не работать с с циклическим просмотром каждой строки в каждой таблице.
Индексы. Их может быть слишком много, а может быть слишком мало. В SQL Server можно непреднамеренно запретить базе данных использовать предполагаемый индекс, если поместить функцию в индексированный столбец.
Уровень экземпляра базы данных
Oracle, SQL Server, PostgreSQL, MySQL или MongoDB, каждая платформа имеет свои особенности и, соответственно, факторы производительности. Посмотрим на эти факторы.
I/O. Главная метрика ввода-вывода обычно количество логических операций чтения, выполненных конкретным оператором SQL. Стремление сократить количество операций логического чтения из базы данных — полезный скилл.
Заблокированные объекты. Блокировка лежит в основе параллелизма транзакций, то есть способности транзакции пройти тест ACID (атомарность, согласованность, изоляция, стойкость). Операторы SQL выполняются в контексте отдельных сеансов, но не все сеансы базы данных постоянно активны. Но даже и такие сеансы также могут быть заблокированы из-за блокировок в базе данных.
Анализ статистики ожидания (Wait Stat). Ожидания связаны с недостатком конкретных ресурсов, такими как процессор, память и сеть. Их недостаток может повлиять на отдельные операторы SQL, которые от них зависят. Также полезно знать, как интерпретировать различные типы ожидания, действующие в вашей базе данных, включая локировку/блокировку (LCK), проблемы ввода-вывода (PAGEIOLATCH), конкуренцию за latch (LATCH) и замедление работы сети (NETWORK).
Параметры. Каждая СУБД имеет конфигурацию, которая может значительно повлиять на её производительность. Сюда входят параметры памяти, параметры оптимизатора, параметры файлов и многое другое.
Файлы. СУБД содержат различные файлы: журналы транзакций, undo-логи и многое другое. Важно убедиться, что эти файлы правильно настроены по части их размера и других связанных параметров для обеспечения оптимальной производительности.
Уровень инфраструктуры
Здесь без сюрпризов. Это уровень операционной системы и/или физического сервера.
CPU. Каждый SQL-оператор требует треда в CPU. Какие из них потребляют больше всего тредов? Какие из них чрезмерно нагружают процессор? Есть ли тенденция к увеличению использования тредов определёнными SQL-операторами?
Память. Когда большие фрагменты ОЗУ заняты чем-то другим, другим запросам приходится ждать обработки. Углубившись в статистику использования памяти, можно определить объем памяти, который потребляет каждый SQL-оператор.
Подсистема хранения. Логические чтения выполняют ввод-вывод из оперативной памяти, но если данных нет в памяти, чтение происходит с диска. Это значительно медленнее и серьёзно влияет на производительность.
Сеть. Если вдруг появился запрос, тратящий большую часть своего времени на ASYNC_NETWORK_IO, это не обязательно означает проблему с сетью; система могла просто передавать клиенту слишком много данных. За этим параметром также нужно следить.
Уровень пользователей и сеансов
Самый обманчивый уровень из всех. Если пользователи жалуются, значит, где-то есть проблема, нужно найти ее и разобраться.
Визуализация пользовательских сессий поможет диагностировать истинную проблему и убедиться, что проблема действительно на стороне базы данных, а не рабочей станции пользователя, где одновременно воспроизводится добрый десяток роликов с Youtube.
Когда вы сталкиваетесь с жалобами на уровне пользователя, возникает невероятный соблазн перейти на уровень инфраструктуры и порешать вопросики там. Некоторые ИТ-команды больше разбираются в оборудовании, чем в диагностике, поэтому они стремятся увеличить вычислительную мощность, память, дисковое пространство и прикрутить 10-гигабитную оптику. В конце концов, если их любимый инструмент — молоток, каждая проблема выглядит как гвоздь.
В физической среде, на виртуальной машине, локально или в облаке, многоуровневый подход к мониторингу базы данных поможет быстро диагностировать истинную причину снижения производительности. С подобными задачами очень хорошо справляется инструмент для мониторинга баз данных — Quest Foglight for Databases. Мы уже несколько лет работаем с этим инструментом и можем сказать, что им вы совершенно точно обеспечите многоуровневый мониторинг, описанный в этой статье.
Подробности о нём можно узнать на специальной странице на нашем сайте.
Почитайте наши статьи о Quest Foglight for Databases на Хабре: