Апр 292011
 

Logminer - специальный инструмент для ретроспективного анализа redo logs базы данных. Он может пригодиться, когда не настроен аудит или, например, для анализа производительности.

Пусть, напиример, перед нами стоит задача: понять, что делалось с таблицей в определённый промежуток времени. Тогда последовательность действий будет такова:

  1. Определим sequence number логов, которые будем восстанавливать.

    SELECT name, SEQUENCE#  
    FROM v$archived_log 
    WHERE 
    	first_time 
    		BETWEEN TO_DATE('01-04-2011 13:00:00','dd-mm-yyyy hh24:mi:ss') AND 
    		TO_DATE('03-04-2011 23:59:59','dd-mm-yyyy hh24:mi:ss')

  2. Создадим каталог, например, /usr/cube и будем восстанавливать туда логи (если временной промежуток большой, и логов, соответственно, много, то можно частями по нескольку штук) с помощью RMAN:

    RUN 
    {
    	ALLOCATE CHANNEL t1 TYPE 'SBT_TAPE';
    	SET ARCHIVELOG DESTINATION TO '/usr/cube/';
    	RESTORE ARCHIVELOG FROM LOGSEQ 741821 UNTIL LOGSEQ 741850;    
    	RELEASE CHANNEL t1;
    }

  3. Добавим логи в список logminer'a.

    -- Для первого лога в списке:
    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( 
    	LOGFILENAME => '/usr/cube/testdb_0000231745.log.ora',
    	OPTIONS => DBMS_LOGMNR.NEW);
    -- Для остальных логов в списке:
    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( 
    	LOGFILENAME => '/usr/cube/testdb_0000231746.log.ora',
    	OPTIONS => DBMS_LOGMNR.ADDFILE);
    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( 
    	LOGFILENAME => '/usr/cube/testdb_0000231747.log.ora',
    	OPTIONS => DBMS_LOGMNR.ADDFILE);
    -- и т.д.

  4. Запуск logminer.

    EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

    Опция DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG указывает, что анализ логов надо производить на той же базе, с которой они получены. В принципе, анализировать логи можно на любой БД, просто надо сделать несколько дополнительных телодвижений. Если кто-то интересуется как, оставьте заявку в комментариях, я напишу отдельный пост.

  5. Анализ данных.
    Данные logminer будут в представлении v$logmnr_contents. Каждый запрос к этому представлению приведёт к полному сканированию всех логов, что займёт много времени. Поэтому можно создать временную таблицу, загрузить в неё либо все данные из v$logmnr_contents, либо часть данных и затем сужать критерии поиска уже в новой таблице. Например, поищем все обращения к базе с помошью SQL*Plus:

    -- Временная таблица (ВНИМАНИЕ: может быть весьма большой)
    CREATE TABLE cube.logmnr AS 
    	SELECT * FROM v$logmnr_contents 
    	WHERE LOWER(session_info) LIKE '%sqlplus%';
     
    -- Теперь посмотрим, что делали с таблицей my_table
    SELECT * FROM cube.logmnr WHERE seg_name LIKE '%MY_TABLE%'; 
    SELECT * FROM cube.logmnr WHERE UPPER(sql_redo) LIKE '%MY_TABLE%' ;

    В представлении v$logmnr_contents нас могут заинтересовать следующие столбцы:

    • seg_name и seg_owner - это имя таблицы и схема, в которой она находится
    • operation - тип операции (INSERT, UPDATE, DELETE, или DDL)
    • username - имя пользователя
    • sql_redo и sql_undo - запрос, чтобы повторить или отменить операцию
    • session_info - куча бесценной информации о сессии (программа, пользователь ОС, etc.)

  6. Перед восстановлением очередной порции логов завершаем работу logminer'a.

    EXECUTE DBMS_LOGMNR.END_LOGMNR();

Upd: Написал новую статью про использование logminer на другой базе.

  3 комментария to “Использование logminer”

  1. Спасибо огромное!
    Я читал множество статей и официальные доки по этой теме, но признаться не всё смог там понять: где-то из-за пермудрёного изложения, оформления или слишком раздутого текста которые просто читать не хочется, часто с углублением куда-то очень глубоко, а где-то наоборот просто недосказанностей или как потом показывает практика откровенных неточностей. Ваша статя приятное исключение, всё очень компактно и красиво оформлено для быстрого использования, отсюда до элементарного проста для понимания.

    Огромная просьба продолжить вот это!
    "В принципе, анализировать логи можно на любой БД, просто надо сделать несколько дополнительных телодвижений. Если кто-то интересуется как, оставьте заявку в комментариях, я напишу отдельный пост."

    Особенно интересует тема словаря в текстовом файле и в Арч Редо Логах. Не понятно время жизни словаря, т.е. окончание известно - момент когда его експортитуют (dbms_logmnr_d.BUILD), а начало жизни словаря: начиная с последнего старта базы? Оракл доки советуют словарь бэкапить/архивировать вместе с Архивными Редо Логами (т.е. dbms_logmnr_d.BUILD), но как? Когда именно, как часто? Одним словом как обеспечить например всем забэкапиным Архивным Редо Логам (например за 1 текущий месяц в оффлайн хранилище) возможность иметь словарь (или словари) для аудита без "пустот" на другом сервере БД (который является полным клоном оригинального по железу и софту и на котором запущена БД из последнего холодного Оракл бэкапа оригинального сервера).

    С уваженим,
    Андрей.

    • Здравствуйте, Андрей.
      Пост напишу на следующей неделе, когда будет время. Боюсь, что времени жизни у словаря нет, это просто "слепок" на момент создания, именно поэтому в документации указано требование выгружать словарь в файл в момент отсутствия на базе каких-либо DDL-операций. Вот цитата из документации:
      Ideally, the dictionary file will be created after all dictionary changes to a database and prior to the creation of any redo logs that are to be analyzed.
      Таким образом, полной целостности аудита, полагаю, добиться не получится, но приблизиться к этому можно двумя путями:
      1. более-менее регулярно (например, с помощью job'а) выгружать словарь в redo logs (в статье напишу, как). Заодно решается проблема с бэкапом словаря, ведь он будет находиться непосредственно в логах.
      2. Раз у Вас в распоряжении есть сервер с клоном базы, то можно просто восстанавливать клон на нужный момент времени (начало интересующего периода) и использовать DICT_FROM_ONLINE_CATALOG, этим сэкономите кучу времени и нервов.

      На мой взгляд, LogMiner не годится в качестве стандартного средства аудита, он нужен скорее разово, только в особых случаях.

      • Здравствуйте,

        спасибо за отзыв, буду ждать Вашу новую статью!

        DICT_FROM_ONLINE_CATALOG на другом сервере - это да, пожалуй, самый надёжный вариант, его буду использовать скорее всего как основной, а словарь пусть тоже будет в Арч Редо Логах.

        Я понимаю, что Logminer не самое лучшее средство для аудита, но у нас в базе (OLTP, GIS - геоинфосистема) используются длинные транзакции, очень важна скорость реакции (очень большая пользовательская нагрузка на запись), поэтому-то и хотелось использовать уже то, что всё равно имеется - Арч Редо Логи и не нагружать систему лишним AUDIT_TRAIL + более проблемный уровень очистки/поддержки необходимого размера баз или файловой системы для логов, дискового пространства, понятно что на все хотелки нужны и ресурсы, , но пока хочется попробовать более оптимально как-раз с ресурсами :)

        С уважением,
        Андрей.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">

(обязательно)

(обязательно)