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

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

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

Если записи только что удалены, база недоступна или завершилась ошибкой миграция, не запускайте восстановление, Flashback, импорт, повторное открытие с RESETLOGS либо массовые исправления на единственном экземпляре. Зафиксируйте время и часовой пояс, перечень доступных копий, archived redo, журналов и снимков. Базу не останавливайте, а копию снимайте как можно раньше — но не самовольно: согласуют не сам факт копирования, а полномочия и способ, то есть кто выполняет, какой командой и как фиксируется результат. Для первого обращения достаточно описания ситуации, без рабочей базы, кошелька TDE и секретов доступа. Если система принадлежит другой стороне или управляется ею, доказательство сохраняют через суд, а не своими силами.

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

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

Archived redo и записи аудита за спорный период скопируйте на отдельный носитель сразу, с контрольными суммами. После этого штатное удаление отработавших архивов не останавливайте: если archived redo перестают вывозиться, область быстрого восстановления заполняется и база встаёт в ожидании места. Требовать бессрочного запрета на удаление архивов, не вывезя копию, — значит остановить рабочую систему; вывезенная копия делает такой запрет ненужным.

Когда нужна экспертиза Oracle Database

Здесь речь идёт об Oracle Database. Если спор касается модулей, SuiteScript, ролей и бизнес-процессов облачной ERP, прочитайте об экспертизе Oracle NetSuite. Специализация на базе данных нужна, когда вывод зависит от внутренних объектов, служебных источников и правил конкретной версии СУБД. Если название Oracle лишь упомянуто в документах, а спор касается всей информационной системы, объёма разработки или исполнения договора, сначала определяют действительный предмет исследования.

Типичные задачи, для которых нужна экспертиза Oracle:

• нужно сопоставить данные, схемы, пользователей, роли, PL/SQL-код, триггеры, задания, индексы или параметры нескольких баз Oracle;
• спор относится к удалению или изменению записей и сохранности следов в redo, аудите, Flashback, резервных копиях либо журналах приложения;
• требуется проверить восстановление к заданному системному номеру изменения (SCN) или времени, полноту RMAN-копии, Data Pump-выгрузки либо причины потери данных;
• нужно исследовать ожидания, блокировки, планы SQL, статистику, память, ввод-вывод, RAC, Data Guard или наблюдавшийся сбой;
• стороны расходятся в оценке миграции в Oracle либо из неё, совместимости схем, типов, PL/SQL и прикладной логики;
• необходимо сопоставить реализацию базы с измеримыми требованиями технического задания, спецификации или SLA.

История конкретных записей подробнее исследуется в рамках экспертизы изменений и удаления данных, перенос — в рамках экспертизы миграции баз данных, а замедления и отказы — при экспертизе производительности и сбоев СУБД. Oracle объединяет эти задачи в одном исследовании только тогда, когда для ответа важны особенности самого продукта.

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

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

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

• версию и параметры базы, состав контейнерной базы (CDB) и подключаемых баз (PDB), схем, табличных пространств, объектов, пользователей, ролей и компонентов;
• содержимое указанных записей в представленной копии и различия между базами, выгрузками, снимками или резервными копиями;
• техническую последовательность операций в пределах сохранённых redo, audit trail, журналов приложения и других источников;
• возможность восстановления к заданному SCN или времени при наличии совместимой физической копии и требуемой последовательности redo;
• механизм формирования значения запросом, триггером, пакетом, процедурой, заданием или связанной частью приложения;
• причины наблюдаемых ожиданий, блокировок, ошибок, деградации SQL, отставания Data Guard или сбоя — если за нужный период сохранились измерения;
• полноту миграции и соответствие конкретных элементов Oracle измеримым требованиям документации.

Redo создаётся прежде всего для восстановления базы, а не как готовый журнал действий сотрудников. LogMiner способен представить часть содержащихся в оперативных и архивных журналах изменений (online и archived redo) через SQL-интерфейс, но результат зависит от версии, набора файлов, словаря, типов данных и настроек supplemental logging. Важно установить, какие виды дополнительного журналирования действовали в момент формирования исследуемого redo: включение настройки после события не добавит недостающие сведения в уже созданные журналы. Пользователь базы, имя программы, адрес клиента, CLIENT_IDENTIFIER или модуль могут сузить круг объяснений, однако сами по себе не доказывают, какое физическое лицо действовало и с каким намерением. Эксперт устанавливает технические обстоятельства в пределах представленных материалов; виновность, умысел, правомерность действий, нарушение договора и иные правовые последствия оценивает суд или иной уполномоченный орган.

Какие объекты исследуются

Набор объектов выбирают под вопрос. Логическая выгрузка может быть достаточна для сравнения схемы и данных, но не заменяет физическую копию, control file, online и archived redo, конфигурацию и аудит, если спор относится к хронологии, восстановлению или состоянию экземпляра.

Data Pump и физические резервные копии

Oracle Data Pump с клиентами expdp и impdp переносит выбранные данные и метаданные логически. Полнота dump file set зависит от режима экспорта, фильтров, прав, доступности объектов и журнала задания. Такая выгрузка не является побайтовой копией файлов базы и обычно не сохраняет физическое состояние блоков, полный контекст экземпляра и всю последовательность redo.

RMAN создаёт и учитывает физические резервные копии: backup set, image copy, копии control file, SPFILE и archived redo. Для восстановления важно установить DBID, incarnation, SCN, состав backup pieces, шифрование, параметры канала и наличие всех требуемых журналов. Простое копирование data files работающей базы без согласованной технологии может дать несогласованный набор. Исходные backup pieces, data files и журналы не используют для проб напрямую: их сохраняют, проверяют контрольные суммы и разворачивают рабочую копию на изолированном стенде.

Архитектура, конфигурация и программные объекты

Исследуются SPFILE или PFILE, управляющие файлы, файл аутентификации администраторов, конфигурация Oracle Net, параметры экземпляра, состав CDB/PDB, RAC, ASM и Data Guard, табличные пространства и файлы данных. На логическом уровне сопоставляют DDL, таблицы, ограничения, индексы, последовательности и identity-столбцы, представления, материализованные представления, синонимы, database links, задания Scheduler, каталоги, Java-объекты, функции, процедуры, пакеты и триггеры. Учитываются редакция и Release Update, операционная система, наборы символов, NLS-параметры и часовые пояса.

Redo, аудит, диагностические данные и мониторинг

Сопоставляются online и archived redo, результаты LogMiner, alert log и trace-файлы из ADR, listener log, unified или традиционный audit trail, fine-grained auditing, журналы приложения и операционной системы, сведения облачного провайдера и системы управления доступом. Сначала проверяют, какие политики аудита действительно действовали в спорный период, когда записи выгружались и очищались, какой контейнер и пользователь отражены в источнике.

Для производительности могут использоваться планы выполнения, V$SESSION, V$SQL, сведения об ожиданиях, блокировках и службах, SQL Monitor, Statspack, AWR и ASH — если эти данные собирались, сохранились и доступны правомерно. Текущие динамические представления не являются полной историей, содержимое shared pool меняется, ASH использует выборку активности, а AWR зависит от интервала снимков и срока хранения. Поэтому отчёт без времени, DBID, instance и container context нельзя автоматически считать полным описанием события.

Как сохранить базу Oracle и технические следы

Работающая база продолжает изменяться: выполняются транзакции, переключаются online redo, архивируются или удаляются журналы, перезаписывается undo, меняются кэш и статистика. Сначала согласуют сбор с минимальным воздействием на систему, а восстановление, импорт и эксперименты проводят на отдельной копии.

До получения копии и начала исследования:

• не выполняйте Flashback, point-in-time recovery, импорт Data Pump, открытие с RESETLOGS, массовое обновление или повторную миграцию поверх единственного спорного экземпляра;
• не удаляйте archived redo, audit trail, alert и trace-файлы и не меняйте политики аудита до фиксации текущей конфигурации;
• сохраните точное время и часовой пояс, версию, DBID, database name и unique name, incarnation, CDB/PDB, instance и thread для каждого источника;
• если у вас есть полномочия и согласован план, создайте копию штатным для этой версии способом, отдельно сохраните манифест, журналы команды и контрольные суммы;
• для RAC, ASM и Data Guard зафиксируйте топологию, роли узлов, последовательности redo, переключения и состояние синхронизации;
• для управляемого сервиса запросите доступные отчёты о резервном копировании, выгрузки аудита, метрики, события обслуживания и сведения о действиях администраторов;
• документируйте, кто создавал, получал и передавал материалы, когда это происходило и какие преобразования выполнялись.

Запрос, называемый «только чтением», всё равно может создавать нагрузку, попадать в аудит, менять кэш и диагностическую статистику. EXPLAIN PLAN и получение фактического плана — разные действия, а выполнение PL/SQL или функции из запроса способно иметь побочные эффекты. Границы допустимого воздействия определяют до подключения, тестовые команды сначала проверяют на копии.

Какие материалы подготовить

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

Для оценки и последующей работы подготовьте:

• цель исследования, проект вопросов, точный период и часовой пояс;
• версию, редакцию и Release Update Oracle, операционную систему или облачный сервис, CDB/PDB, RAC, ASM, Data Guard и связанное приложение;
• DBID, database name, unique name, schema, table, ключ записи, SCN, transaction ID, session ID, пользователя или SQL ID — если они уже известны;
• наборы резервных копий RMAN, recovery catalog либо его согласованную выгрузку, image copies, управляющий файл и SPFILE, archived redo, сведения о Flashback, дамп Data Pump и журналы заданий;
• alert и trace-файлы, listener log, аудит, журналы приложения и ОС, мониторинг, планы SQL и снимки производительности;
• DDL и исходный код PL/SQL, сценарии миграции, карты соответствия полей, отчёты сверки и контрольные выборки;
• договор, техническое задание, SLA, методику испытаний, акты и историю согласованных изменений;
• описание получения материалов, контрольные суммы и процессуальный документ, если экспертиза уже назначена.

Пароли, хранилище ключей прозрачного шифрования данных TDE (wallet), ключи и полные выгрузки рабочих данных не отправляют обычной почтой. До передачи согласуют защищённый канал, необходимость расшифрования на стенде, объём доступа, обезличивание, круг допущенных лиц, срок хранения и порядок возврата либо удаления рабочих копий.

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

Как проводится исследование

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

Методика строится от вопроса и версии Oracle. Сначала проверяют происхождение, контрольные суммы, совместимость и полноту материалов. Затем на изолированном стенде воспроизводят необходимую конфигурацию, документируют команды и результаты, сопоставляют временную шкалу по SCN и часам систем и проверяют альтернативные технические объяснения.

Данные сравнивают воспроизводимыми SQL-запросами, агрегатами и контрольными суммами; схему — по DDL и словарю данных; историю изменений — по redo, LogMiner, аудиту и прикладным журналам; восстановление — по RMAN-копиям и последовательности archived redo. Для производительности рассматривают планы, bind-переменные, ожидания, статистику объектов и системы, конфигурацию памяти, хранилища и сети. Автоматический отчёт или снимок экрана не заменяет описания исходных объектов, параметров команды, ограничений и проверки результата.

Удаление, восстановление и Flashback

Восстановление возможно не всегда. Для RMAN point-in-time recovery восстанавливают физическую резервную копию, созданную до целевой точки, затем применяют доступные инкрементальные копии, если они есть, и необходимые redo до заданного SCN или времени; точный набор зависит от стратегии резервирования. Flashback Database требует заранее включённого flashback logging, сохранённых flashback logs и необходимых online или archived redo за целевой период. Flashback Query зависит от доступности undo, а Flashback Data Archive — от того, был ли он настроен для нужной таблицы и периода. Data Pump, standby database, snapshots и прикладной аудит могут дать дополнительные состояния, но не равнозначны друг другу.

В исследовательской работе обычно сохраняют исходники, разворачивают отдельную копию и получают несколько контрольных состояний, не изменяя оригинал. Перед восстановлением проверяют DBID и incarnation, последовательности по thread, RESETLOGS, NOLOGGING-операции, шифрование и состав контейнеров. Если нужный undo уже перезаписан, archived redo отсутствует, а резервная копия создана после события, прежнее логическое значение может быть недоступно.

Сбои и производительность

Медленный SQL не исследуют только по его тексту. Нужны план и его фактический контекст, bind-переменные, статистика объектов, объёмы данных, ожидания, конкурентная нагрузка, параметры оптимизатора, состояние памяти, дисков и сети. Один план может измениться из-за статистики, профиля, baseline, adaptive-механизмов, версии или окружения. Для RAC дополнительно важны межузловые ожидания и размещение сервисов; для Data Guard — транспорт и применение redo.

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

Миграция в Oracle или из Oracle

Полноту переноса нельзя доказать одним совпадением числа строк. Сопоставляют момент среза, таблицы и разделы, ключи и связи, ограничения, индексы, sequences и identity, LOB, XML, JSON и пространственные данные, представления, materialized views, PL/SQL, триггеры, задания, права, синонимы и database links. Отдельно проверяют преобразование NULL, пустых строк, чисел, дат, временных зон, character set, NLS-правил и длины строк.

Используются журналы Data Pump, SQL*Loader, GoldenGate или другого инструмента, списки ошибок и отклонённых записей, отчёты контрольных запросов и результаты прикладных испытаний. Для больших объёмов задают воспроизводимый способ выборки и вычисления агрегатов или контрольных сумм. Исправный запуск приложения после миграции не доказывает полноту переноса, а техническая сверка базы не подменяет правовую оценку исполнения договора.

Как выбрать формат работы

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

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

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

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

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

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

1. Каковы версия, архитектура и указанные параметры конфигурации представленной базы Oracle?
2. Имеются ли различия в структуре и данных названных схем двух представленных экземпляров, и в чём они состоят?
3. Какие изменения указанного объекта отражены в представленных redo и audit trail за заданный период?
4. Возможно ли восстановить базу или PDB к указанному SCN либо времени по представленным RMAN-копиям и archived redo?
5. Каким механизмом Oracle и связанного приложения сформировано указанное значение?
6. Каковы технические причины зафиксированной ошибки, блокировки, деградации SQL или отставания standby database?
7. Полностью ли перенесены перечисленные схемы, данные и программные объекты по заданным критериям?
8. Соответствуют ли названные измеримые характеристики Oracle конкретным пунктам технического задания или SLA?

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

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

Границы и проверка выводов

Заключение должно позволять проверить путь от объекта к выводу: идентификаторы и контрольные суммы файлов, версию Oracle и стенда, команды и параметры, временной диапазон, результаты и ограничения. Важно отделить online redo от archived redo, Data Pump от физической RMAN-копии, текущие представления от исторических источников, а технического пользователя — от конкретного человека.

При рецензировании проверяют непрерывность журналов, соответствие словаря данным LogMiner, учёт CDB/PDB, RAC threads, incarnation и RESETLOGS, воспроизводимость SQL и восстановления, а также соблюдение экспертом границ специальных знаний. Вопрос о допросе эксперта и назначении дополнительной или повторной экспертизы разрешает суд или иной уполномоченный орган по правилам соответствующего процесса.

Стоимость и срок

Расчёт зависит от числа баз и версий, архитектуры CDB/PDB, RAC или Data Guard, объёма данных и redo, продолжительности периода, состояния RMAN-копий, числа вопросов и необходимости восстановить несколько контрольных точек. Трудоёмкость увеличивают зашифрованные объекты, несовместимые среды, облачные ограничения, анализ большого числа SQL, комплексная миграция и участие специалистов по приложению или информационной безопасности.

Ориентир судебной экспертизы — от 100 000 ₽, срок — от 10 рабочих дней. Точный расчёт возможен после просмотра задачи и перечня материалов. Для начала подготовьте проект вопросов, версию Oracle, схему размещения, спорный период и сведения о доступных RMAN-копиях, Data Pump, redo, аудите и мониторинге.

С чего начать

Опишите событие, укажите точный период и перечислите доступные источники. Не прикладывайте к первому письму рабочую базу, TDE wallet, ключи и пароли. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку: мы проверим компетенцию, поможем уточнить вопросы, предложим безопасный порядок первичного просмотра и сообщим, каких данных не хватает для расчёта.