Oracle лог подключений к базе
Обновлено: 02.07.2024
Как администратор базы геоданных, вы время от времени должны просматривать, кто подключен к базе геоданных, и какие соединения являются блокированными ресурсами. Вам даже, возможно, потребуется удалить некоторые подключения. Например, редактор мог оставить сеанс редактирования открытым, заблокировал данные в сеансе редактирования и запретил другим редакторам доступ к ним. Если число подключений к базе геоданных ограничено, то может потребоваться отключить какого-либо пользователя, который не смог выйти, чтобы освободить подключение. Или вам может потребоваться отключить всех пользователей, чтобы вы могли применить патч к базе данных, восстановить базу данных или сжать базу геоданных.
Если пользователи отсутствуют и не могут выйти сами, то вы можете подключиться к базе геоданных как администратор из ArcGIS Desktop или функции ArcPy и удалить пользовательские подключения.
Внимание:
Соблюдайте осторожность при отключении пользователей. Esri рекомендует вам избегать отключения активных сессий, особенно, если подключенный пользователь находится в процессе редактирования. Следует отключать только сеансы, оставшиеся открытыми, но не использующиеся (например, если пользователь оставил открытый сеанс на выходные), зависшие сеансы, блокирующие объект, или сеансы, попавшие в ситуацию взаимоблокировки.
Для отключения пользователей от базы геоданных в Oracle, администратор базы геоданных должен быть добавлен в роль DBA или иметь права ALTER SYSTEM и SELECT_CATALOG_ROLE.
Сначала определите пользователей, подключенных к базе геоданных. Если необходимо, можно удалить подключения.
Идентификация и удаление подключений из ArcMap
Вы можете подключиться к базе геоданных как ее администратор в ArcMap для просмотра и удаления подключений в диалогом окне Администрирование базы геоданных .
- Запустите ArcMap или ArcCatalog .
- Подключитесь к базе геоданных как администратор базы геоданных.
- Щелкните правой кнопкой подключение к базе геоданных в дереве Каталога, выберите пункт Администрирование и щелкните Администрирование базы геоданных .
- Перейдите на закладку Подключения .
Отобразится список всех сеансов, которые в текущий момент подключены к базе геоданных. Ваш сеанс отображается курсивным шрифтом.
Сеанс будет немедленно отключен от базы геоданных.
Идентификация и удаление подключений с помощью ArcPy
Вы можете запустить функции Python, чтобы создать файл подключения к базе геоданных от имени администратора, использовать этот файл для подключения к базе геоданных и получения списка текущих подключений, а также для удаления подключения к базе геоданных, если необходимо.
-
Создайте файл подключения базы данных с помощью функции CreateDatabaseConnection_management в окне Python. Сохраните имя пользователя и пароль в файле.
В данном примере файл подключения ( oragdb.sde ) создан в папке temp. Он подключается к базе данных spora от имени пользователя sde.
Укажите файл подключения, который вы создали в предыдущем шаге.
Возвращается список подключений пользователей.
Укажите ID подключения, которое нужно удалить. Здесь удаляется подключение с ID 33:
Добрый день! Работая разработчиком Oracle PL/SQL, часто ли вам приходилось видеть в коде dbms_output.put_line в качестве средства debug-а? Стоит признать, что к сожалению, большинство (по моему личному мнению и опыту) разработчиков Oracle PL/SQL не уделяет должного внимания логированию как к «спасательному кругу» в случае возникновения ошибок. Более того, большая часть разработчиков не совсем понимает зачем нужно логировать информацию об ошибках и самое главное, не совсем понимают что делать и как использовать эту информацию в будущем.
Предисловие
Данным постом хотел бы начать цикл статей посвященных «Логированию ошибок» в Oracle PL/SQL. В первую очередь донести мысль до многих разработчиков, о том как можно построить функционал фиксации, хранения логов в БД. На своем опыте продемонстрировать поэтапный процесс создания полноценного логирования в БД. Рассказать как нам удалось создать логирование ошибок, разработать единую нумерацию событий для их дальнейшей идентификации, как поверх логирования «натянуть» мониторинг событий, создать функционал позволяющий увидеть все текущие ошибки в БД в виде таблиц (с указанием частоты возникновения ошибок и кол-ва и т.д.), графиков (отразить динамику роста кол-ва ошибок) и правильно распределить ресурсы для устранения тех или иных ошибок.
Оговорюсь сразу, что на рынке возможно уже есть успешные существующие коммерческие продукты осуществляющие логирование гораздо лучше и качественнее хотя бы, потому что у них есть многолетний опыт внедрения и сопровождения своего продукта в различных компаниях. Я же хочу показать один из множества примеров реализации функционала логирования, которые вполне можно осуществить силами своих разработчиков.
Введение
Модель логирования позволяет реализовать:
Единый подход в обработке и хранении событий
Собственную нумерацию и идентификацию событий происходящих в БД (статья)
Единый мониторинг событий (статья в разработке)
Анализ событий происходящих в БД (статья в разработке)
Описанные выше характеристики указаны в порядке нумерации и каждый следующий пункт (шаг) есть улучшение и усложнение существующей модели. Описание этой модели будет сложно выполнить в рамках одной статьи, поэтому опишем их последовательно. Начнём с первого пункта.
Единый подход в обработке и хранении событий
Основной идеей "Единого подхода в обработке и хранении событий" заключается в создании одного одновременно простого и в тоже время очень сложного правила: "Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события". Простота заключается в том, что легко, в команде разработчиков, на словах договориться об исполнении данного правила. Сложность же заключается в том, что данное правило должно быть установлено на ранних этапах создания вашей БД и выполняться обязательно на протяжении всего жизненного цикла. Внедрить функционал логирования в уже существующие и действующие БД очень сложно (практически не возможно).
Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события. Для этого можно использовать шаблон процедуры (функции) описанный во второй статье.
Наверное сейчас кто-то из читателей может возразить: "Зачем в обязательном порядке?". А всё очень просто, если вы разработчик PL/SQL и вы не согласны с этим правилом, то вот вам пример. Посмотрите на свой текущий проект более внимательно. Скорее всего вы найдете какое-нибудь логирование событий реализованное кем-то, когда-то. Вспомните сколько раз вы обращались к этому логированию при решении багов. Именно в таких ситуациях, когда есть срочность по времени в исправлении бага, вы или ваши коллеги начинают использовать dbms_output.put_line в качестве экспресс-дебага (быстрый способ получения значений переменных используемых в коде). Согласитесь, что для исправления бага мало знать в какой процедуре, в каком запросе и на какой строке возникла ошибка, необходимо знать параметры запроса на которых возникает ошибка. И вот тут нам на помощь приходит "Логирование событий", потому что помимо места возникновения ошибки мы узнаем параметры вызова процедуры, в которой возникает ошибка и это очень упрощает исправление бага.
Первая статья посвящена базовому функционалу «Логирования событий». В простейшей реализации это одна общая таблица и пакет процедур для работы с ней. Для создания и демонстрации логирования, нам необходимо реализовать следующие объекты БД (весь список объектов с их исходными кодами представлен в Git):
Таблица messagelog - единая таблица логов. Именно в данной таблице будет храниться информация о дате и времени события, об объекте где происходит событие, типе события с указанием кода, текста и параметров. В нашем примере, столбец backtrace вынесен в отдельную таблицу messagelog_backtrace для удобства.
Примечание. Представленное ниже описание таблицы является демонстрационным с минимальным набором столбцов для создания простейшего функционала логирования. Наличие дополнительных столбцов и их тип данных может меняться в зависимости от целей и задач логирования.
Также, учитывайте пожалуйста, что создание партиции требует как минимум Oracle EE. Создание партиции вне указанной версии Oracle приведет к нарушению лицензионного соглашения.
Данная статья более подробно исследует возможности администратора базы данных (DBA) в обнаружении SQL инъекций в Oracle. В этой статье мы сфокусируем внимание на исследовании некоторых методов трассировки данных и анализе лог файлов. Наша цель - показать читателю доступные решения.
Введение
В прошлом году были написаны две статьи о SQL инъекциях в Oracle. В них были описаны различные методы SQL инъекций, используемые в Oracle, даны простые примеры об их работе и некоторые предложения по защите от нападений злоумышленников, использующих эти методы. Статьи можно найти здесь:
Данная статья более подробно развивает данную тему и исследует возможности администратора базы данных (DBA) в обнаружении SQL инъекций в Oracle. Возможно ли вообще обнаружение SQL инъекции? Если да, то какие средства и методы должны использоваться?
В этой статье мы сфокусируем внимание на исследовании некоторых методов трассировки данных и анализе лог файлов. Наша цель - показать читателю доступные решения. В этой статье не упоминаются коммерческие решения. Так как настоящие инструменты обнаружения SQL инъекций включают в себя написание синтаксических анализаторов или фильтров для анализа SQL выражений, то полный показ таких методов, к сожалению, выходит за рамки короткой статьи.
Можно ли обнаружить SQL инъекцию?
Ответ короткий - определенно да. вероятно. То есть да, возможно обнаружить SQL инъекцию, но вероятно, что не всегда и не во всех случаях, и не всегда в реальном времени. Причины этого сложны и их много:
Существует много различных форм атак с помощью SQL инъекций - они ограничены только воображением хакера и предвидением DBA (или его нехваткой) в защите базы данных и обеспечении наименьшего количества необходимых привилегий.
Идентификация нелегальных SQL выражений является непростой задачей. Причиной возможности SQL инъекций является использование в приложениях динамического SQL запроса. Это означает, что очень тяжело, а в некоторых случаях даже невозможно определить все легальные SQL выражения. Если легальные выражения невозможно определить, тогда мы будем считать их нелегальными. Также не всегда просто отличить нормальное администрирование от нападения, т.к. нападающий может захватить и использовать учетную запись администратора. При обнаружении SQL инъекций, неизбежны всевозможные дополнения или сокращения SQL выражений при их синтаксическом анализе. Имена таблиц и представлений должны быть извлечены и проверены, для того чтобы увидеть, были ли они изменены. Для полезности методики, мы не должны слишком сильно затрагивать производительность базы данных. Также необходимы подтверждения данных, таких как имена пользователей и временных меток данных.Обнаружение попыток SQL инъекций вообще и конкретно против Oracle возможно. Как возможно этого добиться, и какие данные являются доступным? В данной статье мы попытаемся исследовать эти вопросы.
Сначала необходимо определить граничные условия, или какие действия должны быть обнаружены. Затем нужно выбрать возможные бесплатные решения в рамках Oracle и как можно их использовать для достижения хорошего эффекта.
Некоторые возможные коммерческие решения
Нет никаких коммерческих решений, обнаруживающих попытки SQL инъекций, конкретно в базах данных Oracle. Существует определенное количество программ межсетевой защиты, которые объединяют Oracle proxy и несколько средств IDS, поддерживающих Oracle. В настоящее время множеством компаний серьезно разрабатываются проекты IDS приложений под Oracle, и возможно эти средства смогут обнаруживать SQL инъекции. Для должной работы большинства существующих коммерческих программ, необходимо использование правил и сигнатур, определенных для специфических случаев Oracle.
Некоторые бесплатные решения
Невозможно определить полный список всех типов и сигнатур SQL инъекций, но в качестве отправной точки можно выделить следующее:
SQL, в котором предложение UNION, вызывает обращение к другой таблице или представлению. SQL, в котором добавлен необоснованный SUB-SELECT. SQL, в котором предложение WHERE было зациклено, путем дополнения строки типа '' = '' или 1=1. SQL, в котором происходит необоснованный вызов встроенных или сохраненных процедур. SQL, в котором выполнен доступ к системным таблицам и/или пользовательским приложениям и идентификационным таблицам. SQL, в котором, предложение WHERE было сокращено с помощью комментария - -- Анализ некоторых классов ошибок, указывающих на то, что выбранные классы имеют неправильное количество аргументов или неправильный тип данных. Это может указать на то, что кто-то пытается создать дополнительный запрос, используя предложение UNION.Главное, сначала сделать все как можно проще; попытка делать что-то слишком сложное с помощью встроенных средств, в данном случае не принесет никакого эффекта. Важно не “перегнуть палку” с предположениями о том, что действительно является легальным SQL, а что создано хакером. Остерегайтесь ложных плюсов. Делайте это просто и действенно - используйте, если возможно, более одного метода, расширяйтесь и учитесь.
Любое средство или система, используемые для обнаружения SQL инъекций, могут идентифицировать большинство возможностей из вышеупомянутого списка. В попытке определить, откуда приходят данные для анализа SQL, следующие шаги должны быть полезными для одного и нескольких методов:
Необходим как можно более быстрый захват SQL, отправленного базе данных. Необходимо выполнение анализа SQL, для проверки некоторых или всех вышесказанных случаев, указывающих на SQL инъекцию. Необходимо получение пользовательских и timestamp данных.Фокусирование внимания на захвате SQL, а если возможно, то на получении timestamp и пользовательской информации, также как и возможный дальнейший анализ, приводят нас к следующему списку возможностей:
Сетевые снифферы/IDS средства, типа snort (не используются в дальнейших экспериментах) Бесплатные анализаторы сетевых пакетов, типа snoop Использование инструментов типа Oracle Log Miner (Сборщик логов) и возможно анализ повторных логовИз-за некоторых проблем нельзя находиться в полной уверенности. Средства аудита используются исключительно для более явных случаев. Если при шифровании сетевого трафика используются дополнительные параметры Oracle, то будет затруднено выделение SQL из сети. Использование трассировки имеет тенденцию генерировать огромные количества данных и потреблять системные ресурсы. Любой метод, не позволяет обнаружить инструкции Select.
Если невозможно обнаружить SQL инъекцию в реальном времени, то лучше узнать позже, чем вообще не знать, что это произошло.
Примеры с решениями
Теперь мы можем работать с некоторыми простыми примерами попыток SQL инъекций, используя пример из предыдущих статей. Первый шагом мы создаем типовую клиентскую таблицу, добавляем данные и создаем демонстрационную процедуру get_cust.
Ниже приведен пример попытки SQL инъекции, который будет использоваться далее, для того чтобы увидеть обнаружен ли он:
Теперь мы проанализируем, какие из трассировок, пакетов, контрольной и внутренней информации, смогли записать любое из доказательств выполнения этого запроса.
Сборщик логов
Oracle поддерживает две хранимые процедуры базы данных DBMS_LOGMNR и DBMS_LOGMNR_D, позволяющие архивировать и интерактивно восстанавливать лог файлы, которые будут проанализированы. Восстановленные лог файлы содержат всю информацию, для воспроизведения любого действия в базе данных. Они используются для моментального восстановления, для транзакций и совместимости данных. Однако существуют некоторые, перечисленные ниже, проблемы с функциональными возможностями Сборщика логов.
Если используется база данных MTS (Multi Threaded Server), то Сборщик логов не может использоваться из-за внутреннего распределения памяти этой программы. Сборщик логов использует PGA память, невидимую потокам, используемым в MTS. Программа не поддерживает должным образом цепные и перемещаемые строки, а также не полностью поддерживаются объекты. Анализ индексных таблиц и кластеров также не поддержан.SQL, сгенерированный Сборщиком логов, не такой как SQL, выполненный пользователем. Это происходит, из-за того, что восстановленные лог файлы сохраняют достаточно данных для изменения значений на уровнях строк и столбцов, так что невозможно воспроизвести первоначальные составные выражения.
Некоторые преимущества Сборщика логов:
Анализ не могут выполнять в исходной базе данных, поэтому архивные лог файлы могут быть перемещены в специализированную базу данных и проанализированы автономно. Существует инструмент с графическим интерфейсом, доступный через Oracle Enterprise Manager (OEM)Для того чтобы сделать практичным использование этого инструмента, база данных должна быть в режиме ARCHIVELOGMODE, а для размещения пользовательской информации значение transaction_auditing в файле инициализации должно быть true.
Сборщик логов очень эффективное средство для анализа событий и расследования, когда точно эти события произошли внутри базы данных, и кто это сделал. Это может успешно использоваться, для помощи в восстановлении, например, случайно удаленной таблицы.
Восстановленные лог файлы, также могут быть проанализированы вручную. Хорошая статья, демонстрирующая это, может быть найдена здесь.
Теперь мы можем просмотреть пример и исследовать содержание архивных лог файлов. Сначала проверьте, находится ли база данных в ARCHIVELOGMODE, определите, где записаны архивные лог файлы и, наконец, что включен аудит имен пользователей.
Обнаружение, какой именно пользователь выполнил команду:
Сначала создайте словарь Сборщика логов:
Найдите правильный архивный лог файл:
Теперь загрузите архивный лог файл в Сборщик логов:
Наконец необходимо найти результаты:
Первое, что можно заметить это то, что Сборщик логов не обрабатывает команды select и отображает вывод в 9i. Модуль Сборщика логов не поддерживает выборки, поскольку они не сохраняются в восстановленных лог файлах. Возможно использование Сборщика логов, для онлайнового чтения восстановленных лог файлов, но я оставляю эти эксперименты читателям. Даже притом, что SQL инъекция может быть обнаружена в insert, delete и update выражениях, Сборщик логов не является подходящим средством для обнаружения SQL инъекций. Это, также как и некоторые другие проблемы, упомянутые выше, является недостатком в способности Сборщика логов обнаруживать команды select.
Анализатор сетевых пакетов
Главная проблема в анализаторе пакетов при подключении к базе данных Oracle это то, что сетевой протокол Oracle является собственным и не открытым. Это имеет ли значение при установлении, были ли попытки SQL инъекций? Вероятно да, поскольку доступ к протоколу был бы более эффективным инструментом для решения этой задачи. При отсутствии доступа к протоколу и желания это воспроизводить, задача ограничена только захватом строк ASCII-текста из шины. Существуют как преимущества, так и недостатки этого метода:
Система может быть реализована на отдельном сервере, позволяющем проводить анализ в реальном масштабе без влияния на исходную базу данных.
Пакеты должны проанализированы близко к источнику и в той же самой подсети, для гарантирования проходов всех пакетов через анализатор. Если используются дополнительные защитные параметры Oracle применяемые для шифрования сетевых пакетов или любые другие решения, используемые для шифрования, то анализатор сетевых пакетов не будет работать. Если, как в нашем примере, пробную попытка SQL инъекции передают как запрос к хранимой процедуре, то не будет виден настоящий внутренний динамический SQL. Вместо этого вы будете просто видеть напечатанный в команде.Анализ каждого пакета приводит к генерации огромного количества данных. Конвейеризация пакетов через программу-фильтр смягчает эту проблему.
Для демонстрации, мы будем использовать snoop на Solaris, чтобы увидеть то, что видимо внутри сетевых пакетов. Запустите snoop, и SQL из сеанса SQL*PLUS:
С помощью этого метода очевиден немедленный успех, так как SQL захватывается вместе с SQL инъекцией. Как и в других методах описанных в этой статье, должно быть выполнено следующее:
Должна быть запущена программа - фильтр, это необходимо для синтаксического анализа SQL выражений и определения потенциальных попыток SQL инъекций. Для реального использования, программа-фильтр также должна извлекать информацию о времени создания файла и IP адрес источника из заголовков сетевых пакетов. Выделение пользователя базы данных может быть чрезвычайно трудным, поскольку, для выделения информации об учетных записях входа в систему, должны быть проверены все предыдущие сетевые пакеты. Все это дает потребность в сохранении предыдущих пакетов или информации о них и их последовательностях.В качестве простого решения, анализ сетевых пакетов, может выступать в роли альтернативного решения, обеспечивающего достаточно простые фильтры/синтаксические анализаторы, написанные в Perl или C. Нашей целью является вывод возможных преступлений, выделяя SQL, timestamp и src и dest IP из пакетного потока.
Анализ внутренних сетевых пакетов Oracle (sqlnet trace)
Извлечение сетевой информации из Oracle возможно, используя средство трассировки SQL*NET, Net*8 или Oracle networking (смотря какое из названий подходит к версии вашей базы данных).
Средства трассировки доступны для большинства сетевых сервисов Oracle, таких как: listener, Oracle names, connection manager, names control utility, и конечно Oracle networking client and server. В этом примере мы сконцентрируем внимание на трассировке сервера.
Существуют некоторые недостатки в использовании сетевых трассировочных файлов, как средства поиска SQL инъекций:
Трассировочные файлы очень быстро увеличиваются в размерах, используя при этом огромное количество дискового пространства. При неправильном управлении существует опасность переполнения диска, и как следствие отказ в обслуживании. Хотя и возможно определить уникальное имя и расположение трассировочного файла, но Oracle добавляет идентификатор процесса (PID) в конец имени файла трассировки. PID можно увидеть в следующих SQL:Для включения трассировки необходимо в файле $ORACLE_HOME/network/admin/sqlnet.ora добавить следующие строки:
Параметры определяют, где должен быть записан файл трассировки, как он должен называться, а также его уровень. Существует четыре используемых уровня трассировки: OFF, USER, ADMIN и SUPPORT. Они повышают детализацию трассировки от OFF до SUPPORT; уровень SUPPORT учитывает содержание сетевых пакетов.
Давайте снова запустим наш пример из SQL*PLUS на Windows-клиенте и посмотрим, что было сгенерировано в a файле трассировки. Трассировочный файл, как и ожидалось, называется pf_trace_616.trc. Ничего себе! Этот файл содержит в себе 4005 строк, и это только из-за соединения и запуска следующей команды:
Выполнив поиск дампа пакета, в файле трассировке, мы можем найти попытку SQL инъекции, посланной базе данных:
При использовании файлов трассировки SQL*Net, существует еще ряд проблем, помимо перечисленных выше:
Был еще раз необходим синтаксический анализатор, для извлечения SQL текста из дампов пакета и определения были ли SQL инструкции попыткой SQL инъекции. PID, используемый как часть имени файла трассировки не известен, до тех пор, пока не подсоединится пользователь, и не запустится фоновый процесс. Если бы имена файлов не были уникальны подобно snoop, то трассировка могла бы быть пропущена через фильтр, и проблема использования дискового пространства была бы решена. Трассировочные файлы могут регулярно проверяться простым сценарием, который проверяет трассировочные файлы, в которых больше не запущен фоновый процесс. В этом случае они могут быть обработаны и удалены. Длительные сеансы генерировали бы огромные трассировки и таким образом не могли бы идеально контролироваться. Проще всего определить пользователей операционной системы и пользователей базы данных, включающих в себя трассировку SQL*NET, поскольку эта информация может быть найдена в представлениях v$process и v$session со сведениями об OS PID.Этот метод не удобен, для выполнения простой утилиты обнаружения SQL инъекций. Ресурсные проблемы только затрудняют управление и работу. Можно использовать это более расчетливо, когда подозреваемый инцидент произошел и где использование трассировки может контролироваться на ограниченном отрезке времени или числе пользователей.
Что произойдет, если не указать LOGGING/NOLOGGING при создании объектов БД?
Точнее, как будут вести себя объекты БД с опцией LOGGING/NOLOGGING и без этой опции?
LOGGING/NOLOGGING помогает управлять опцией Direct path writes (прямой путь записи в файлы данных), чтобы уменьшить генерацию REDO и UNDO. Это один из нескольких способов контролировать деликатный баланс между восстанавливаемостью данных и производительностью.
Немного общей информации по архитектуре
REDO это то, как Oracle обеспечивает прочность (durability), "D" в ACID. Когда транзакция завершается, изменения не обязательно сразу же сохраняются в файлах данных. Это ускоряет процесс и позволяет фоновым процессам справляться с некоторыми задачами. REDO - это описание изменений. Оно сохраняется быстро, на нескольких дисках, как журнал изменений. Если сервер теряет питание через доли секунды после фиксирования изменений, БД может через записи REDO убедиться, что изменения не потеряны, и востановить изменения ещё не записанные в файлы данных.
UNDO помогает обеспечить согласованность (consistency), "C" в ACID. В нем хранится описание того, как отменить изменение. Эта информация используется для отката изменений и другими процессами, которые читают таблицу и должны знать, какое значение соответствовало более раннему периоду времени.
Direct path writes не использует REDO, UNDO, кэш и некоторые другие функции, идёт непосредственная запись в файлы данных. Это быстрая, но потенциально опасная опция во многих средах, вот почему существует так много запутанных опций для управления ею. Direct path writes применяется только к INSERT , и только в сценариях, описанных ниже.
Если ничего не указывать, опция по умолчанию самая безопасная, LOGGING .
Множество способов управления Direct Path Writes
LOGGING/NOLOGGING - один из нескольких вариантов управления Direct path writes.
Посмотрите на эту таблицу из AskTom, чтобы понять, как различные опции работают вместе:
FORCE LOGING может отменить все эти настройки. Наверняка, есть другие параметры, о которых мало кто знает. И, конечно же, есть много ограничений, которые препятствуют прямому пути - триггеры, внешние ключи, кластер, индекс-организованные таблицы и т.д.
Правила в большей степени ограничены для индексов. Индекс всегда будет генерировать REDO во время DML выражений. Только DDL операторы, такие как CREATE INDEX . NOLOGGING или ALTER INDEX . REBUILD по индексу NOLOGGING не будет генерировать REDO.
Почему так много возможностей? Потому что восстанавливаемость невероятно важна, и разные стороны могут иметь разные взгляды на этот вопрос. И иногда решения одних людей должны преобладать над решениями других.
Разработчики решают на уровне запроса - "Вид на вставку". Много странных вещей может произойти с подсказкой /*+ APPEND */ , и разработчики должны тщательно выбирать, когда его использовать.
Архитекторы принимают решение на уровне объекта - "Вид на таблицу". Некоторые таблицы, независимо от того, как разработчик решит их вставить, всегда должны быть восстановлены.
*Администраторы БД" выбирают с видом на БД или табличные пространства, NOARCHIVELOG и FORCE LOGING . Может быть, организация просто не заботится о восстановлении конкретной БД, поэтому установят БД в режим NOARCHIVELOG . А может у организации есть строгое правило, что все должно быть восстанавливаемо, поэтому установят табличное пространство в режим FORCE LOGGING .
Читайте также: