Судебная экспертиза базы данных IBM Db2

Экспертиза IBM Db2 нужна, когда спор зависит от содержимого базы, журналов транзакций, резервных копий, аудита, конфигурации, сбоя, производительности или результата миграции. Исследование охватывает не только таблицы: специалист устанавливает семейство продукта и платформу, версию и уровень исправлений, параметры экземпляра и базы, действовавший режим журналирования, образы резервных копий (backup images), диагностические материалы и связь операций с прикладной системой. Это специализированное направление экспертизы баз данных и СУБД.

Для предварительной оценки достаточно описания события и перечня сохранившихся материалов. По версии, платформе, журналам, копиям, настройкам аудита и исследуемому периоду определяют, проверяема ли поставленная техническая версия и какой стенд потребуется. Например, при циклическом журналировании и наличии только поздней резервной копии прежнее состояние обычно восстановить невозможно. Предварительная оценка позволяет уточнить вопросы и перечень необходимых источников.

Если база недоступна, данные удалены или реплика отстаёт, не запускайте восстановление поверх единственного экземпляра, принудительный takeover, реорганизацию и исправляющие утилиты до фиксации состояния. Сохраните время и часовой пояс, сообщения ошибки, версию, конфигурацию, перечень журналов и копий. Экземпляр не останавливайте, а копию снимайте как можно раньше — но не самовольно: согласуют не сам факт копирования, а полномочия и способ, то есть кто выполняет, какой командой и как фиксируется результат. Если система принадлежит другой стороне, доказательство сохраняют через суд.

Отдельно о том, что будет, если ответить не удастся. Задачу, по которой уже из присланных материалов видно, что вывода не получится, мы просто не берём в работу и говорим об этом сразу. Это не обещание положительного вывода: отказ на входе означает лишь, что невозможность видна уже из перечня материалов. Если же невозможность выясняется по итогам полноценного исследования, это результат, а не пустой счёт: заключение объясняет, почему ответа нет и чего именно не хватило. В споре такой вывод часто закрывает вопрос: обоснованный ответ, что при циклическом журналировании записи спорного периода перезаписаны, показывает суду границы имеющихся источников. Назначать ли после этого дополнительную или повторную экспертизу, решает назначивший её орган. Бывает и частичная невозможность: тогда указывают, на какие вопросы ответ получен, а на какие нет и по какой причине.

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

Журналы за спорный период скопируйте на отдельный носитель сразу, с контрольными суммами; если для этого нужна остановка экземпляра, её согласуют с владельцем системы заранее. После этого штатное удаление отработавших журналов не останавливайте: при заполнении пути активных журналов Db2 прекращает выполнение транзакций, и база фактически становится недоступной. Отдельно посмотрите тип журналирования: при циклическом прежние записи перезаписываются по кругу, восстановление на момент времени невозможно, и ждать здесь тем более нечего.

Для первого обращения не нужно передавать рабочую базу, ключи и пароли: достаточно описания события, версии, типа журналирования и спорного периода. Копия базы содержит сведения о людях и коммерческую информацию, поэтому защищённый канал, объём доступа, необходимость обезличивания, круг допущенных лиц, срок хранения и порядок удаления рабочих копий согласуют до передачи.

Сначала устанавливают, какой именно Db2 исследуется

Название Db2 объединяет разные продуктовые линии. Db2 for Linux, UNIX and Windows (LUW), Db2 for z/OS и Db2 for i нельзя считать одной и той же средой: у них различаются архитектура, системные каталоги, форматы носителей, журналы, команды и процедуры сопровождения. Вопрос «что происходило в DB2» без платформы, версии и идентификатора базы недостаточно определён.

Приведённые ниже параметры LOGARCHMETH, утилита db2ckbkp, HADR и связанные команды относятся прежде всего к Db2 LUW. Для Db2 for z/OS и Db2 for i эксперт выбирает штатные средства и терминологию соответствующей платформы и версии; переносить команды LUW на них нельзя.

На первом этапе:

• устанавливают продуктовую линию, операционную систему, архитектуру, версию и уровень исправлений;
• фиксируют имя экземпляра, имя и псевдоним базы, её database seed, каталоги и пути хранения;
• определяют локальное, виртуальное, контейнерное, облачное размещение либо управляемый сервис;
• проверяют кодовую страницу, территорию, правила сортировки (collation), часовой пояс и синхронизацию часов;
• отделяют фактические данные Db2 от выгрузок, отчётов и кэшей прикладной системы.

Ни расширение файла, ни слово DB2 в документации сами по себе не идентифицируют объект. Методика и совместимый стенд выбираются только после проверки происхождения материалов.

Что может и чего не может установить эксперт

Ответ зависит от сохранности конкретных источников. Эксперт может описать структуру и данные, сопоставить состояния, проверить образ резервной копии, определить диапазон доступного восстановления с накатом журналов (rollforward recovery), проанализировать включённый аудит, диагностику и состояние HADR, воспроизвести ошибку или проверить миграцию. Каждый вывод связывается с идентифицированным объектом, командой и результатом.

При достаточных материалах эксперт может установить:

• какие таблицы, представления, индексы, ограничения, триггеры, процедуры, функции, пакеты (packages), роли и права существовали в исследуемом состоянии;
• какой период охватывают образы резервных копий и сохранённые журналы транзакций и возможно ли восстановление до допустимой заданной точки;
• какие события отражены в db2audit, db2diag.log, журнале административных уведомлений, файле истории и журналах приложения;
• соответствуют ли настройки журналирования, резервного копирования, HADR и обслуживания установленным требованиям;
• чем объясняется зафиксированный сбой или замедление и подтверждается ли предложенная техническая причина;
• полностью ли перенесены объекты и данные и сохранилась ли значимая семантика.

Журнал транзакций предназначен прежде всего для восстановления, а не для готового ответа о физическом пользователе. Имя входа в базу, наименование приложения, адрес клиента или сеанс характеризуют технический контекст. Сопоставление данных Db2 с аутентификацией, журналами приложения, ОС и сети позволяет связать событие с техническими идентификаторами. Вопросы о том, какое физическое лицо действовало и с каким умыслом, разрешает суд или иной уполномоченный орган.

Материалы для исследования

Состав зависит от задачи и продуктовой линии. Для каждого объекта ведут инвентарную запись: источник и владелец, лицо, выполнившее получение, средство и его версия, команды и параметры, время начала и окончания с часовым поясом, размер и SHA-256 завершённой копии. Исходный экземпляр обозначают как мастер-копию и сохраняют неизменным, для анализа создают отдельную рабочую копию. Каждую передачу регистрируют, а после неё повторно вычисляют SHA-256 и сопоставляют с предыдущим значением. Секреты отделяют от основного комплекта и передают только согласованным способом.

В комплект обычно включают:

• согласованный образ всех каталогов базы, контейнеров, путей хранения и журналов, полученный документированным способом, а также сведения о группах хранения (storage groups) и табличных пространствах (tablespaces);
• полные, инкрементальные и разностные образы резервных копий, журналы создания копий и результаты проверки;
• пути к активным, зеркальным и архивным журналам, доступные файлы журналов транзакций, параметры LOGARCHMETH1 и LOGARCHMETH2, их фактические значения и параметры извлечения; отдельно отмечают значение LOGRETAIN у LOGARCHMETH1, если журналы удерживались и перемещались пользователем;
• выгрузки конфигурации экземпляра и диспетчера баз данных, переменные реестра, DDL и каталоги;
• архивы db2audit, действовавшие политики аудита, настройки и результаты контролируемого извлечения;
• db2diag.log, журнал административных уведомлений, файл истории, trap- и FODC-материалы, дампы и сообщения ОС;
• для HADR — роли и состояния, конфигурация основного и резервного серверов (primary/standby), данные db2pd -hadr или MON_GET_HADR, события переключения (takeover) и сетевые журналы;
• SQL, планы выполнения, снимки кэша пакетов, данные мониторинга, журналы приложения, ETL и расписаний;
• техническое задание, схема миграции, SLA, акты, переписка и точная формулировка спорного периода.

Обычная файловая копия каталогов работающей базы может оказаться несогласованной. Для Db2 LUW при доступном сервере создают документированную резервную копию командой BACKUP DATABASE ... ONLINE, при необходимости с INCLUDE LOGS, либо снимок/клон по поддерживаемой для установленной версии Db2 и конкретного хранилища процедуре. Онлайновая копия доступна только базам с архивным журналированием: при циклическом журналировании эта команда не выполнится, и копию получают на остановленной базе. Тип журналирования проверяют заранее — от него же зависит, возможно ли восстановление на момент времени. Для разделяемого онлайн-зеркала (online split mirror) перед разделением IBM требует SET WRITE SUSPEND, а после получения копии — документированно возобновить запись; копия должна охватывать все пути базы, определённые конфигурацией и DBPATHS, и необходимые журналы. Произвольный «атомарный» снимок или снимок согласованного после сбоя состояния (crash-consistent snapshot) нельзя заранее считать пригодной базой восстановления без проверки процедуры и пробного восстановления. Простую файловую копию получают только после корректной деактивации базы или остановки экземпляра с фиксацией команды и результата.

Если доступен только логический экспорт, по нему можно исследовать перенесённые данные и часть DDL, но нельзя автоматически делать выводы о прежнем физическом состоянии, полном составе журналов, удалённых объектах или настройках исходного экземпляра.

Передача копии, в которой есть сведения о людях или охраняемая законом тайна, требует законного основания. По назначенной экспертизе объекты поступают от назначившего органа; вне процесса — от обладателя сведений и в объёме, необходимом для ответа на поставленные вопросы. Обезличивание при этом обсуждают не как уступку, а как способ передать меньше, чем есть. Эксперт не разглашает сведения, ставшие известными ему в связи с исследованием, а рабочие копии удаляет по окончании работы.

Журналы, образы резервных копий и восстановление

Для Db2 LUW при LOGARCHMETH1=OFF и LOGARCHMETH2=OFF используется циклическое журналирование: автоматическое восстановление после сбоя (crash recovery) доступно, но база не поддерживает восстановление с накатом журналов. Если хотя бы один метод архивирования отличен от OFF, база настраивается для rollforward recovery. Конкретное место и способ сохранения зависят от метода: Db2 может архивировать журналы в заданное хранилище, а при значении LOGARCHMETH1=LOGRETAIN пользователь сам удерживает и перемещает файлы из пути активных журналов. Одна конфигурация не доказывает, что нужная непрерывная последовательность действительно архивирована и извлекается.

Для Db2 LUW при архивном журналировании после RESTORE выполняют накат журналов до END OF BACKUP, END OF LOGS либо до допустимого момента времени (point-in-time). Точка должна быть не раньше минимально допустимой границы восстановления (minimum recovery time); для резервной копии, созданной онлайн, — позже её завершения. Нужны все требуемые активные и архивные журналы одной цепочки, совместимые с образом и версией. Восстановление на момент времени возвращает базу или табличное пространство к целостному состоянию на выбранный момент, а не выборочно отменяет один DELETE; необходимые строки извлекают и сопоставляют на отдельном стенде.

При исследовании сопоставляют идентификаторы базы и образа резервной копии, время, тип и последовательность копий, начальные и конечные позиции журналов, журналы, табличные пространства и историю команд. db2ckbkp проверяет структуру и часть целостности образа и показывает метаданные, но не заменяет пробное восстановление и не доказывает логическую правильность данных. RESTORE и накат журналов выполняют на совместимом отдельном стенде с протоколированием команд и результатов.

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

db2audit, db2diag.log и другие следы

В Db2 LUW средство аудита Db2 может регистрировать события на уровне экземпляра и базы, включая административные действия, проверки полномочий и доступ к объектам. Для вывода проверяют, был ли аудит включён в нужный период, какие категории и политики действовали, куда писались записи, как выполнялись db2audit archive и db2audit extract и не прерывалась ли последовательность. Для Db2 for z/OS и Db2 for i применяют аудит и журналы соответствующей платформы, в том числе QAUDJRN в IBM i, а не переносят команды LUW. Отсутствие записи вне реально настроенного охвата не доказывает отсутствия события.

db2diag.log — основной диагностический источник о сообщениях компонентов, ошибках и отдельных операционных событиях в Db2 LUW. Его полнота зависит от DIAGLEVEL, путей и ротации; это не журнал всех SQL-изменений. Журнал административных уведомлений, файл истории, FODC, trap-файлы, журналы ОС, клиента и приложения дополняют картину. Временные отметки приводят к общей шкале только после проверки часовых поясов и синхронизации часов.

HADR, отказ и производительность

В HADR для Db2 LUW журнальные данные передаются с основного сервера (primary) на резервный (standby) и воспроизводятся там. Эксперт проверяет режим синхронизации, роли, состояние пары, позицию приёма на standby (STANDBY_LOG_POS), позицию применения (STANDBY_REPLAY_LOG_POS), разрыв primary–standby (HADR_LOG_GAP), разрыв приём–применение (STANDBY_RECV_REPLAY_GAP), задержку, разрывы соединения и последовательность переключения (takeover). Резервный сервер повышает доступность, но не является независимой резервной копией: логически корректное удаление или ошибочная операция может быть передана на реплику.

Для причин сбоя и низкой производительности сопоставляют db2diag.log, журналы уведомлений и ОС, кэш пакетов, функции мониторинга, планы выполнения, ожидания блокировок и взаимоблокировки, буферные пулы, сортировки, журналирование, задержки табличных пространств и хранилища, очереди HADR, параметры памяти и нагрузку приложения. Один текущий снимок не доказывает состояние в прошлом. Тесты планов и конфигурации проводят на репрезентативной копии, фиксируя версию, статистику, параметры и набор данных. Замедления и отказы сами по себе исследует экспертиза производительности и сбоев СУБД.

Как проверить миграцию Db2

Равное число строк не подтверждает эквивалентность систем. Сначала сопоставляют структуру базы: схемы и владельцев, таблицы, ключи и ограничения. Затем проверяют типы и точность чисел, столбцы идентификации (identity) и последовательности (sequences) с их текущими состояниями, временные метки и часовые пояса, строковые типы GRAPHIC/VARGRAPHIC/DBCLOB, единицы измерения длины строк (string units) и кодовые страницы, NULL, значения по умолчанию, вычисляемые столбцы, правила сортировки, индексы, представления, триггеры, процедуры и функции, пакеты, права и задания по расписанию.

Перечень выбирают по фактическому каталогу и карте миграции; он не ограничивается указанными объектами. По применимости дополнительно сверяют табличные пространства, группы хранения и секционирование, псевдонимы удалённых объектов (nicknames), объекты федеративного доступа (federated objects), материализованные таблицы запросов (MQT), пользовательские типы, модули и глобальные переменные, темпоральные определения (temporal definitions), разрешения на строки, маски столбцов/LBAC, роли и предоставленные права (grants), а также значимые параметры конфигурации базы и диспетчера баз данных. Вывод db2look проверяют по системному каталогу и тестам, поскольку он не гарантирует воспроизведение всех характеристик объектов.

Отдельно проверяют отклонённые строки, преобразования LOB/XML/DECFLOAT, усечение и округление, правила сопоставления регистрозависимых имён, порядок повторного запуска и изменения после контрольной точки. Воспроизводимая сверка указывает версии источника и приёмника, момент фиксации, карту соответствия, запросы, алгоритм контрольных сумм и допустимые различия. Когда предметом спора становится сам перенос, а не устройство базы, задачу закрывает экспертиза миграции баз данных.

Примеры вопросов на экспертизу

При судебной экспертизе окончательный круг вопросов определяет суд, а в иных предусмотренных законом процедурах — орган или лицо, назначившие экспертизу. Вопросы о виновности, умысле, правовой квалификации события, нарушении договора и ответственности разрешает суд или иной уполномоченный орган. Эксперт отвечает на поставленные вопросы в пределах специальных знаний и представленных материалов; о неясности вопроса, выходе за пределы компетенции или недостаточности материалов он в установленном порядке сообщает суду, органу или лицу, назначившим экспертизу.

До назначения стороны могут использовать приведённые ниже формулировки как предложения о технических вопросах. Для Db2 полезно указать платформу, экземпляр и базу, версию, период и часовой пояс, конкретный объект и технический критерий. Например, можно предложить исследовать, какие источники отражают удаление строк таблицы X в период Y и с какими техническими идентификаторами связана операция, либо до какого момента возможно непрерывное восстановление базы N по представленным копиям и журналам. Дополнительные примеры:

1. Какие пользовательские и программные объекты содержатся в представленном состоянии базы Db2?
2. Охватывают ли представленные образы резервных копий и журналы момент, указанный в постановлении, и возможно ли восстановить базу на этот момент?
3. Какие операции за спорный период отражены в представленных записях аудита и иных журналах?
4. Можно ли связать установленную операцию с конкретным идентификатором авторизации базы данных, сеансом или приложением?
5. Имеются ли признаки повреждения базы, образа резервной копии либо отдельного табличного пространства?
6. Каковы технические причины зафиксированного отказа или недоступности?
7. Как менялись роли и состояние HADR и существовал ли подтверждаемый разрыв журналов?
8. Соответствует ли конфигурация журналирования и резервного копирования заданным требованиям?
9. Полностью ли перенесены перечисленные объекты и данные в целевую СУБД?
10. Воспроизводятся ли спорные результаты запросов на представленном состоянии и при заданных параметрах?

Как проходит экспертиза

Методика выбирается под вопрос, однако процесс должен позволять другому специалисту проверить ход рассуждения. Исходный объект сохраняют, а изменяющие операции выполняют на рабочих копиях.

Готовое чужое заключение проверяет рецензия на заключение экспертизы баз данных и СУБД. Собственное исследование обычно проходит так:

1. Уточняется объект. Фиксируются продуктовая линия, платформа, версия, экземпляр, база, период и критерий.
2. Инвентаризируются материалы. Описываются базы, журналы, образы резервных копий, аудит, диагностика, HADR, приложение и документы.
3. Обеспечивается сохранность. Для мастер-копии фиксируются источник, средство и его версия, команды, время с часовым поясом, размер и SHA-256. Для анализа создаётся рабочая копия; каждую передачу регистрируют и завершают повторной проверкой SHA-256.
4. Создаётся стенд. Подбирается совместимая версия; RESTORE, накат журналов и проверки выполняются только на рабочих копиях.
5. Проверяются гипотезы. Сопоставляются данные, каталоги, журнальные позиции, временные отметки, конфигурация и альтернативные причины.
6. Формулируются выводы. Отдельно указываются подтверждённые факты, интерпретация и ограничения.

Стоимость, срок и формат результата

Ориентир по стоимости экспертизы IBM Db2 — от 100 000 ₽, ориентировочный срок — от 10 рабочих дней. Точный расчёт зависит от продуктовой линии и версии, числа баз и узлов, объёма, сохранности журналов и копий, шифрования, HADR, необходимости совместимого стенда, периода, количества вопросов и срочности.

Если судебная экспертиза уже назначена, назначенный по делу эксперт не принимает от одной стороны напрямую дополнительные резервные копии, журналы и выгрузки и не даёт ей частную оценку по существу поручения: вопросы, доступ и новые материалы идут через назначившего субъекта. Это не исключает обращения стороны к другому, не назначенному по делу специалисту — за консультацией или рецензией по законно полученным материалам. Предшествующую содержательную работу специалиста для одной стороны раскрывают при рассмотрении его кандидатуры; допустимость назначения и возможный отвод решает уполномоченный субъект с учётом мнения участников. Чтобы снизить риски, роли консультанта стороны и кандидата в судебные эксперты целесообразно разделять.

Результатом может быть консультация по материалам, внесудебное исследование, заключение специалиста, судебная экспертиза или рецензия на выполненное исследование. Процессуальный статус задаётся документом о назначении и применимыми правилами, а вопрос о приобщении и доказательственном значении решает суд. Рецензент проверяет идентификацию Db2 и объектов, команды, версии инструментов, воспроизводимость, логическую связь выводов и границы компетенции.