Проверка целостности бд oracle

Обновлено: 06.07.2024

Для правильной диагностики проблем СУБД Oracle необходимо знать утилиты отладки, предоставляемые Oracle. Необходимо понимать такие операции, как чтение дампов управляющего файла или файлов трассировки.

Трассировочные файлы Oracle

Главным является файл журнала оповещений (alert.log), который содержит важнейшую информацию о работе БД, в ходе диагностики его следует проверять в первую очередь.

Помимо alert.log Oracle автоматически генерирует два файла трассировки. Один из них - фоновый файл трассировки, создается фоновыми процессами DBWR и LGWR. Эти файлы трассировки могут и не создаваться при запуске системы, в зависимости от наличия информации для записи.

Файл трассировки второго типа создается соединением пользователя с БД и называется пользовательским файлом трассировки.

Такой файл появляется, только если сеанс пользователя наталкивается на ошибку.

Имена файлов трассировки имеют стандартный формат и зависят от используемой ОС. В среде UNIX фоновый файл трассировки выглядит как ORA_PID_PROCESS.trc, а пользовательский файл - PROCESS_ID.trc. При этом ORA_PID представляет идентификатор процесса Oracle, а PROCESS_ID - системного процесса, создавшего файл трассировки.

Для отладки поддерживаются различные средства диагностики. Для выгрузки в файлы трассировки диагностической информации можно подключить определенные события. Для диагностики повреждений диска и памяти применяются некоторые специальные параметры init.ora . Эти параметры не задаются при нормальной работе БД, т.к. они снижают ее производительность.

Задание событий трассировки

Приведем способы задания событий трассировки:

-выгрузить содержание всего управляющего файла

alter session set events 'immediate trace name controlf level 10'; (rdbms/mesg/oraus.msg)

-выгрузить состояние системы для диагностики проблем, связанных с зависанием

alter session set events 'immediate trace name systemstate level 10';

-выгрузить содержание всех заголовков файлов данных

alter session set events 'immediate trace name file_hdrs level 10';

-выгрузить стек ошибки и процесса (напр., ошибка ORA-00604)

alter session set events ' 604 trace name errorstack forever' ;

При задании событий с помощью init.ora используются следующие строки:

EVENT = "604 TRACE NAME ERRORSTACK FOREVER" - выгружается стек ошибок каждый раз, когда процесс встречает ошибку ORA-00604;

EVENT = "10210 TRACE NAME CONTEXT FOREVER, LEVEL 10" - контролируется целостность каждого блока при чтении с диска в кэш.

Наиболее распространенные коды событий:

10013 и 10015 -- применяются при диагностике проблем, связанных с повреждением сегментов отката.

event = "10015 trace name context forever"

10029 и 10030 -- информация о началах и остановках сеансов.

10210 и 10211 -- проверяются блоки данных, считываемые в область SGA

event = "10210 trace name context forever, level 10"

10231 и 10232 -- пропустить поврежденные блоки в ходе сканирования таблицы и выгрузить их в файл трассировки

alter session set events '10231 trace name context off';

event = "10231 trace name context forever, level 10"

Первый оператор отключает проверку блоков для данного сеанса. Второй включает проверку всех блоков БД, считываемых любым

процессом в область SGA.

Анализ журнала с помощью LogMiner

Архивные файлы журналов повторов очень важны, особенно для восстановления БД. Для того, чтобы прочитать внесенные в БД изменения, которые содержаться в архивном файле журнала повторов, необходимо открыть указанный файл и изучить его содержимое.

Для этого существует специальный инструмент под названием LogMiner.

Для работы с этим инструментом необходимо:

1. Установить utl_file_dir в init.ora

2. Запустить $ORACLE_HOME/rdbms/admin/dbmslogmnrd.sql

3. SQL> EXECUTE dbms_logmnr_d.build('dictionary.ora', '<utl_file_dir>');

4. SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE(

LogFileName => ' /oradata/test/arc/test454.arc', Options => dbms_logmnr.NEW);

для каждого добавляемого к списку файла журнала удалить

5. EXECUTE DBMS_LOGMNR.START_LOGMNR(DictFileName => <utl_file_dir/dictionary.ora');

6. select scn, log_id, username, sql_redo, sql_undo from v$logmnr_contents where username='SCOTT';

список всех изменений, выполненных пользователем SCOTT

7. SQL> EXEC DBMS_LOGMNR.END_LOGMNR;

Поиск и исправление поврежденных блоков данных с помощью модуля DBMS_REPAIR

Для устранения повреждений в блоках, таблицах и индексах Oracle предлагает инструмент DBMS_REPAIR.

Этот модуль позволяет:

- мягко повреждать блоки, чтобы показать, что они повреждены;

- пропускать поврежденные блоки в ходе полного сканирования таблицы или индекса;

- обслуживать ставшие ненужными строки индекса, которые указывают на поврежденные блоки данных;

- перестраивать списки свободной памяти для указанной таблицы или индекса.

Создание таблиц администрирования модуля DBMS_REPAIR

1. sqlplus " / as sysdba"

2. Создать (по желанию) табличное пространство.

3. SQL> EXEC DBMS_REPAIR.ADMIN_TABLES( ' REPAIR_ADMIN', 1, 1, 'REPAIR_TS');

SQL> EXEC DBMS_REPAIR.ADMIN_TABLES( ' ORPHAN_ADMIN' , 2, 1, 'REPAIR_TS');

Если нужно удалить таблицу:

SQL> EXEC DBMS_REPAIR.ADMIN_TABLES( ' ORPHAN_ADMIN' , 2, 3, NULL);

Чтобы очистить таблицу (удалив все ее строки ) :

SQL> EXEC DBMS_REPAIR.ADMIN_TABLES( ' ORPHAN_ADMIN' , 2, 2, NULL);

Проверим на повреждения таблицу data схемы prod. Допустим, что в схеме sys была создана таблица repair_admin

1. sqlplus " / as sysdba"

SQL> VARIABLE A NUMBER;

'REPAIR_ADMIN' , NULL, NULL, NULL, NULL, :A);

4. SELECT RELATIVE_FILE_ID FILE,

MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;

Исправление поврежденных блоков с помощью процедуры DBMS_REPAIR.FIX_CORRUPT_BLOCKS

1. VARIABLE A NUMBER;

2. EXEC DBMS_REPAIR.FIX_CORRUPT_BLOCKS( 'PROD', 'DATA', NULL, 1, 'REPAIR_ADMIN', NULL, :A);

3. Проверим помечены ли элементы блока, как программно поврежденные:

SELECT RELATIVE_FILE_ID FILE,

MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;

Пропуск поврежденных блоков с помощью процедуры DBMS_REPAIR.SKIP_CORRUPT_BLOCKS

EXEC DBMS_REPAIR.SKIP_CORRUPT_BLOCKS ( 'PROD', 'DATA', 1,1);

Использование процедуры DBMS_REPAIR.DUMP_ORPHAN_KEYS для просмотра висячих ключей

EXEC DBMS_REPAIR.DUMP_ORPHAN_KEYS ('PROD', 'SNO_IDX', NULL, 2, 'REPAIR_ADMIN',

'ORPHAN_ADMIN', NULL, :A);

SELECT SCHEMA_NAME, INDEX_NAME, INDEX_ID, TABLE_NAME, KEYROWID, KEY,

DUMP_TIME FROM ORPHAN_ADMIN;

Чтобы перестроить список свободной памяти таблицы DATA:

EXEC DBMS_REPAIR.REBUILD_FREELISTS( 'PROD', 'DATA', NULL, 1);

ORADEBUG

Утилита oradebug предоставляет доступ к структурам памяти процессов Oracle, стекам и т.д.

С его помощью можно генерировать дамп состояния процесса, а также выгружать структуры области SGA.

Кроме того, для уже работающего процесса можно активизировать какое-либо событие.

SQL> oradebug help

SQL> oradebug setospid 9431

процесс менеджера прикрепляется к процессу Oracle под Unix номером 9431.

пример выхода: Oracle pid: 12, unix process pid: 9431, image: oraclevk803

SQL> oradebug unlimit

размер файла трассировки устанавливается в unlimited

SQL> oradebug event 10046 trace name context forever, level 12

активизируется событие трассировки SQL

SQL> oradebug flush

сбрасываем трассировочную информацию на диск

нельзя так делать для фоновых оракловых процессов - может произойти остановка базы

Хотя ещё нужно проверять чтобы scn в заголовках всех файлов в БД был одинаков.
А то получим несогласованную БД.

а что понимается под целостностью в SQL Server 2012?
там есть такая задача. Что конкретно она проверяет я не знаю.
Наверное да, нужно проверять соответствие дочерних записей родительским.

Хотя ещё нужно проверять чтобы scn в заголовках всех файлов в БД был одинаков.
А то получим несогласованную БД.

Никак не могу этого сделать!
Так уж случилось, что потребовалось создать табличку с rowdependencies, а
старую табличку с ограничениями, индексами и триггерами удалить, так как в одной
схеме нельзя держать два сегмента с одинаковыми именами.

Вот я боюсь что в момент манипуляций с таблицами произойдёт несогласованность данных:

1. создали новую таблицу-копию старой с rowdependencies.
2. все строки из старой таблицы cкопировали в новую таблицу-копию
3. сохранили старые имена для ограничений, индексов, триггеров для старой таблицы.
4. удалили старую таблицу с ограниченями, индексами, триггерами.
5. создали ограничения, индексы, триггеры для новой таблицы-копии, как у старой.

Я боюсь, что в момент между удалением старой таблицы и созданием ограничений в новой таблице
произойдёт какой-нибудь DML и в результате можно получить несогласованную БД.

Хочется проверить после всех манипуляций, что мы ничего не поломали в БД .

Чего-то хочу - не знаю кого, кого знаю - не хочу?

Вот я боюсь что в момент манипуляций с таблицами произойдёт несогласованность данных:

Хочется проверить после всех манипуляций, что мы ничего не поломали в БД .

У меня манипуляции проводит владелец схемы.

А если кто-то возьмёт и удалит (по ошибке, или специально) какое-то ограничение, а потом
создаст его заново? Например админ Вася в нетрезвом виде удалил ограничение из таблицы -
внешний ключ. А потом создал это ограничение заново, после удаления. А после этого всего -
вообще уволился.

Мы получим несогласованную БД. Придёт новый админ, и нужно будет проверить есть ли
косяки в БД.

Вот я боюсь что в момент манипуляций с таблицами произойдёт несогласованность данных:

Хочется проверить после всех манипуляций, что мы ничего не поломали в БД .

Oracle 11.2.0.1
Windows 2008 r2 x64

помогите с rename. при попытке переименовать таблицу получаю:

ORA-26563
Attempt to rename a replicated table, an updatable materialized view table
or the master table of a materialized view for which a materialized view log has beencreated.

я нашёл мат вью лог на исходную таблицу которую хочу переименовать (удалить)

тут проблемка. у меня имя исходной таблицы и мат вью лога совпадают.
поэтому как oracle поймёт при select откуда я хочу записи выбрать, из мат вью лога или из таблицы?

В том числе: Проверьте состояние экземпляра Oracle, проверьте процесс обслуживания Oracle, проверьте процесс мониторинга Oracle, всего три части.

1.1 Проверьте состояние экземпляра Oracle

Среди них «STATUS» указывает текущее состояние экземпляра Oracle, которое должно быть «OPEN», «DATABASE_STATUS» указывает текущее состояние базы данных Oracle, которое должно быть «ACTIVE».

1.2 Проверка состояния журнала онлайн Oracle

Выходной результат должен иметь более 3 записей (включая 3) записи, «STATUS» должен быть не «INVALID», не «DELETED». Примечание: «СТАТУС» пуст для обозначения нормального.

1.3 Проверьте состояние табличного пространства Oracle

СОСТОЯНИЕ должно быть ОНЛАЙН на выходе.

1.4 Проверьте состояние всех файлов данных Oracle

«STATUS» на выходе должно быть «ONLINE». или:

«STATUS» на выходе должно быть «ДОСТУПНО».

1.5 Проверка на недействительные объекты

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

1.6 Проверьте состояние всех сегментов отката

«СОСТОЯНИЕ» всех сегментов отката на выходе должно быть «ОНЛАЙН».

2. Проверьте использование ресурсов, связанных с Oracle

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

2.1 Проверьте значения соответствующих параметров в файле инициализации Oracle

Если LIMIT_VALU-MAX_UTILIZATION <= 5, это означает, что параметры инициализации Oracle, связанные с RESOURCE_NAME, должны быть скорректированы. Можно изменить, изменив файл параметров инициализации Oracle $ ORACLE_BASE / admin / CKDB / pfile / initORCL.ora.

2.2. Проверка соединения с базой данных

Проверьте, находится ли текущий номер подключения сеанса в пределах нормального диапазона.

Среди них: SID сеанса (сеанса), идентификационный номер;

USERNAME - имя пользователя, с которого был установлен разговор;

Какой инструмент используется для сеанса PROGRAM для подключения к базе данных;

STATUS Текущее состояние этого сеанса. ACTIVE означает, что сеанс выполняет определенные задачи. INACTIVE означает, что текущий сеанс не выполняет никаких операций.

Если установлено слишком много подключений, это потребляет ресурсы базы данных. В то же время некоторые «зависшие» подключения, возможно, придется очистить вручную. Если администратор базы данных хочет отключить сеанс вручную, выполните:

(Обычно не рекомендуется использовать этот метод для разрыва соединения с базой данных, поэтому иногда сеанс не будет отключен. Легко вызвать прерывание соединения. Рекомендуется проверить spid операционной системы через sid и использовать ps –ef | grep spidno для подтверждения spid Не фоновый процесс ORACLE. Используйте команду kill -9 операционной системы, чтобы разорвать соединение)

Примечание. В приведенном выше примере сеансы с SID от 1 до 10 (столбец USERNAME пуст) являются фоновыми процессами Oracle и не выполняют никаких операций в этих сеансах.

2.3 Проверьте место на системном диске

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

Filesystem Size Used Avail Use% Mounted on

/dev/sda5 9.7G 3.9G 5.4G 42% /

/dev/sda1 479M 16M 438M 4% /boot

/dev/sda2 49G 19G 28G 41% /data

none 1014M 0 1014M 0% /dev/shm

2.4 Проверьте использование табличного пространства

select f.tablespace_name,
a.total,
f.free,
round((f.free / a.total) * 100) "% Free"
from (select tablespace_name, sum(bytes / (1024 * 1024)) total
from dba_data_files
group by tablespace_name) a,
(select tablespace_name, round(sum(bytes / (1024 * 1024))) free
from dba_free_space
group by tablespace_name) f
WHERE a.tablespace_name = f.tablespace_name(+)
order by "% Free";

Если процент простоя% Free составляет менее 10% (включая 10%), обратите внимание на увеличение файла данных для расширения табличного пространства вместо использования функции автоматического расширения файла данных. Пожалуйста, не добавляйте слишком много файлов данных в табличное пространство.Принцип увеличения файлов данных заключается в том, что размер каждого файла данных составляет 2G или 4G, а максимальное ограничение для автоматического расширения составляет 8G.

2.5 Проверьте некоторые расширенные ненормальные объекты

Если запись возвращается, расширение этих объектов почти достигло максимального значения расширения, когда оно было определено. Для этих объектов необходимо изменить параметры его структуры хранения.

2.6 Проверка содержимого системного табличного пространства

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

2.7 Проверьте следующее расширение объекта и максимальное значение расширения табличного пространства

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

3. Проверьте результаты резервного копирования базы данных Oracle

содержать:
a. Проверьте информацию журнала резервного копирования базы данных;
б. Проверьте время создания файлов в томе резервной копии;
c. Проверьте электронную почту пользователя оракула.
3.1. Проверьте информацию журнала резервного копирования базы данных

Предположение: временный каталог для резервного копирования - / backup / hotbakup, нам нужно проверить результат резервного копирования 22 июля 2009 года, а затем использовать следующую команду для проверки:

cat /backup/hotbackup/hotbackup-09-7-22.log|grep –i error

Файл журнала сценария резервного копирования - hotbackup-month-date-year.log, находящийся во временном каталоге резервного копирования. Если в файле есть «ОШИБКА:», это означает, что резервное копирование не было успешным, и существует проблема, которую необходимо проверить.

3.2 Проверьте время создания файлов в томе резервной копии

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

3.3 Проверьте электронную почту пользователя оракула

4. Проверьте производительность базы данных Oracle

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

4.1. Проверка базы данных на события ожидания

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

4.2 Получить оператор SQL с самым высоким показанием диска

4.3. Найти десятку плохо работающих SQL

4.4 Пять систем с наибольшим временем ожидания ждут сбора событий

4.5 Проверка долгосрочного SQL

4.6. Проверьте процесс, который потребляет больше всего процессора

4.7 Проверьте таблицы с высокой фрагментацией

4.8 Проверьте соотношение ввода-вывода в табличном пространстве

4.9 Проверьте соотношение ввода / вывода файловой системы

4.10 Проверка на тупик и обработку

Запрос информации о текущем объекте блокировки:

Уровень Oracle убивает сессию:

Сеанс уничтожения на уровне операционной системы:

5. Проверьте базу данных процессора, ввода-вывода, производительность памяти

Запишите использование ЦП, ввода-вывода, памяти и т. Д. Базы данных, используйте команды vmstat, iostat, sar, top и другие для сбора информации и проверки информации для определения использования ресурса.

5.1 Использование процессора:

top - 10:29:35 up 73 days, 19:54, 1 user, load average: 0.37, 0.38, 0.29

Tasks: 353 total, 2 running, 351 sleeping, 0 stopped, 0 zombie

Cpu(s): 1.2% us, 0.1% sy, 0.0% ni,98.8% id, 0.0% wa, 0.0% hi, 0.0% si

Mem: 16404472k total, 12887428k used, 3517044k free, 60796k buffers

Swap: 8385920k total, 665576k used, 7720344k free, 10358384k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

30495 oracle 15 0 8329m 866m 861m R 10 5.4 7:53.90 oracle

32501 oracle 15 0 8328m 1.7g 1.7g S 2 10.6 1:58.38 oracle

32503 oracle 15 0 8329m 1.6g 1.6g S 2 10.2 2:06.62 oracle

Обратите внимание на синий шрифт выше, эта часть представляет оставшийся ЦП системы. Когда среднее значение падает ниже 10%, это рассматривается как ненормальное использование ЦП. Вам необходимо записать это значение и записать состояние как ненормальное.

5.2 Использование памяти:

total used free shared buffers cached

Mem: 2026 1958 67 0 76 1556

-/+ buffers/cache: 326 1700

Swap: 5992 92 5900

Как показано выше, синяя часть представляет общую память системы, красная часть представляет память, используемую системой, а желтая часть представляет оставшуюся память системы. Когда оставшаяся память составляет менее 10% от общей памяти, она считается ненормальной.

5.3 Ситуация с системным вводом / выводом:

Linux 2.6.9-22.ELsmp (AS14) 07/29/2009

avg-cpu: %user %nice %sys%iowait %idle

0.16 0.00 0.05 0.36 99.43

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

sda 3.33 13.16 50.25 94483478 360665804

avg-cpu: %user %nice %sys%iowait %idle

0.00 0.00 0.00 0.00 100.00

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

sda 0.00 0.00 0.00 0 0

Как показано выше, синий шрифт указывает состояние чтения и записи диска, а красный шрифт указывает состояние ожидания ввода-вывода ЦП.

5.4 Системная нагрузка:

12:08:37 up 162 days, 23:33, 15 users, load average: 0.01, 0.15, 0.10

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

5.5 Проверьте, есть ли процесс зомби

Некоторые процессы зомби блокируют нормальную работу других сервисов и регулярно убивают процессы зомби.

5.6 Проверьте ссылку на линию / миграцию

Примечание. Обычно таблица с длинными необработанными столбцами имеет ссылку на строку, находит строку миграции и сохраняет ее в таблице chained_rows. Если такой таблицы нет, выполните ее.

Вы можете увидеть, какие строки являются перенесенными строками по таблице имя_хеда, head_rowid в таблице chained_rows

5.7 Регулярный статистический анализ
Для системы, использующей Oracle Cost-Based-Optimizer, необходимо регулярно собирать и обновлять статистическую информацию объектов данных, чтобы оптимизатор мог составить правильный план объяснения на основе подготовленной информации. Статистическая информация должна обновляться в следующих ситуациях:
а. Изменения в приложении
б. Масштабная миграция данных, миграция исторических данных, импорт других данных и т. д.
C. Количество данных изменилось
Проверьте, нужно ли обновлять статистику таблицы или индекса, например:

Если количество строк сильно отличается, таблица должна обновлять статистическую информацию, поэтому рекомендуется собирать статистическую информацию раз в неделю, например:

5.8 Проверьте частоту попаданий в буфер

Если частота попаданий ниже 90%, вам нужно увеличить параметр базы данных db_cache_size.

5.9 Проверка коэффициента попадания в общий пул

Если оно ниже 95%, вам необходимо настроить приложение для использования переменных связывания или настроить размер общего пула параметров базы данных.

5.10 Проверьте область сортировки

Если отношение диск / (памятка + строка) слишком велико, вам нужно настроить sort_area_size (workarea_size_policy = false) или pga_aggregate_target (workarea_size_policy = true).

5.11 Проверьте буфер журнала

Если повторное размещение буфера повторных попыток / повторных записей превышает 1%, вам нужно увеличить log_buffer.

6. Проверьте безопасность базы данных

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

6.1 Проверьте информацию журнала безопасности системы

Каталог файла журнала безопасности системы находится в / var / log, который в основном проверяет информацию журнала пользователя об успешном или неудачном входе в систему.

Проверьте журнал успешного входа в систему:

Jan 8 08:44:43 rac2 sshd[29559]: Accepted password for root from ::ffff:10.10.10.6 port 1119 ssh2……

Проверьте журнал неудачного входа в систему:

Jan 9 10:30:44 rac2 sshd[3071]: Invalid user ydbuser from ::ffff:192.168.3.5

Jan 9 10:30:56 rac2 sshd[3071]: Failed password for invalid user ydbuser from ::ffff:192.168.3.5 port 36005 ssh2

Jan 10 22:44:38 rac2 sshd[21611]: Failed password for root from ::ffff:10.10.10.6 port 1723 ssh2

6.2 Проверьте пользователя, чтобы сменить пароль

В системе баз данных часто бывает много пользователей, таких как: сторонние системы мониторинга баз данных, демонстрационные пользователи во время первоначальной установки базы данных, пользователи-администраторы и т. Д. Пароли этих пользователей часто пишутся, и многие люди знают, что они будут скрытыми мотивами. Люди привыкли атаковать систему и даже изменять данные. В число пользователей, которым необходимо изменить свои пароли, входят:
Пользователи администратора базы данных SYS, SYSTEM; другие пользователи.
После входа в систему введите cat / etc / passwd в командной строке, чтобы проверить, есть ли среди перечисленных пользователей неиспользуемые или странные учетные записи. Если он существует, он записывается как ненормальный.

Метод изменения пароля:

7. Другие проверки

В этом разделе мы в основном проверяем, является ли текущая задача crontab нормальной и не сработала ли работа Oracle. Существует шесть частей.

7.1 Проверьте, является ли текущая задача crontab нормальной

7.2 Сбой работы Oracle

Если есть проблемы, рекомендуется перестроить задание, например:

7.3. Контролировать рост объема данных

Согласно ежедневной проверке на этой неделе, найдите объекты базы данных с быстро расширяющимся пространством и примите соответствующие меры:

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

--- Расширить табличное пространство

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

Выполнить оператор SQL:

Таким образом, команда SQL для создания управляющего файла будет сгенерирована в каталоге USER_DUMP_DEST (указан в файле параметров инициализации).

7.4 Проверка на неуспешные индексы

Примечание. Обычно состояние индекса в таблице разделов равно N / A. Если индекс не выполнен, перестройте его, например:

Регулярное создание резервных копий производственной базы данных Oracle является обязательным, но эти резервные копии никак не помогут, если по какой-то причине окажутся непригодными для использования. Этап тестирования резервных копий часто игнорируется в процессах резервного копирования и восстановления. К сожалению, многие администраторы осознают его необходимость, будучи уже в тяжелых обстоятельствах.

Создаваемые резервные копии файлов базы данных могут становиться бесполезными во время восстановления по нескольким причинам: из-за повреждения файлов данных и журналов повторного выполнения, из-за случайного перезаписывания файлов, из-за дефектов на ленте и даже из-за несуществующих файлов. Поэтому лучше обзавестись привычкой регулярно тестировать производственные резервные копии в соответствие с графиком. Это поможет перехватывать любые повреждения данных. Под повреждением подразумевается несоответствие данных тому виду, в котором они должны быть. Здесь интерес главным образом представляет так называемое повреждение блоков (ошибки блоков), которое может быть как логическим, так и физическим.

Обнаружение ошибок в носителях

Повреждения в носителях могут возникать по массе причин, начиная от ошибки пользователя и неполадок в программном обеспечении операционной системы и заканчивая дефектными дисками, ошибками диспетчера логических томов ( Logical Volume Manager — LVM) и неисправными микросхемами памяти. Они могут приводить, в свою очередь, к возникновению повреждений в управляющих файлах, журналах повторного выполнения, словаре данных, табличных данных и данных индексов.

Обнаружение ошибок в блоках данных

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

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

Существует несколько методов, которые можно применять для обнаружения повреждений в блоках данных БД Oracle. Во-первых, можно устанавливать несколько специальных параметров инициализации и тем самым обеспечивать возможность перехвата информации о поврежденных блоках. Во-вторых, можно использовать утилиты наподобие DBVERIFY и DBMS_REPAIR или команду ANALYZE и тем самым обеспечивать возможность выявления повреждений в блоках данных. Эти методы не являются взаимоисключающими; напротив, их следует рассматривать как дополнения друг к другу, поскольку каждый обладает своими собственными привлекательными возможностями. В следующих подразделах более подробно рассказывается о том, как применять каждый из этих приемов.

Настройка параметров инициализации

Установив такой параметр инициализации, как DB_BLOCK_CHECKSUM, можно заставить базу данных Oracle вычислять контрольные суммы (check-summing) для каждого блока данных и сохранять их в заголовках блоков. Тогда при чтении данных эти контрольные суммы сравниваются и выявляются поврежденные блоки данных. В Oracle рекомендуют оставить для параметра DB_BLOCK_CHECKSUM принятое для него по умолчанию значение TYPICAL (равнозначное значению TRUE, которое использовалось в предыдущих версиях). Согласно заявлениям Oracle, использование этой функции в режиме TYPICAL приводит к увеличению накладных расходов всего лишь на 1–2%. Применение ее в другом возможном режиме FULL приводит к увеличению накладных расходов уже на 4–5%.

Параметр DB_BLOCK_CHECKING является более сложным и предусматривает выполнение проверки блоков данных и индексов только тогда, когда они действительно изменяются. Он обнаруживает повреждения до присвоения блокам данных статуса поврежденных. По умолчанию для него используется значение OFF. Другие значения, которые он может принимать: LOW, MEDIUM и FULL. Его применение может приводить к увеличению объема накладных расходов на 1–10%; этот объем напрямую зависит от количества выполняемых в базе данных операций обновления и вставки. При наличии возможности справляться с дополнительными накладными расходами, в СУБД Oracle рекомендуют устанавливать для этого параметра значение FULL. Конфигурировать этот параметр можно в файле init.ora, как показано в следующем примере, где для него выбрано значение LOW:

Его также можно конфигурировать и динамически с помощью оператора ALTER SESSION:

Еще одним параметром инициализации, который можно устанавливать, является DB_ULTRA_SAFE. Этот параметр применяется для управления значениями параметров DB_BLOCK_CHECKSUM и DB_BLOCK_CHECKING. В случае если для него оставляется принятое по умолчанию значение (OFF), база данных устанавливает для обоих связанных с выявлением повреждений параметров значение TYPICAL, что означает выполнение минимальных проверок и, следовательно, меньшее потребление ресурсов ЦП. В случае же установки для него значения DATA_ONLY или DATA_AND_INDEX, база данных будет устанавливать для двух связанных с выявлением повреждений параметров значение FULL, что будет приводить к выполнению более интенсивных проверок на предмет повреждений и, следовательно, большему потреблению ресурсов.

Применение команды ANALYZE

Команду ANALYZE удобно применять для перехвата поврежденных блоков данных. Например, выполнение показанной ниже команды ANALYZE приведет к проверке каждого блока данных в таблице customer и, в случае обнаружения любых поврежденных блоков — добавлению всех подозрительных строк в таблицу invalid_rows:

Помимо выполнения проверки на предмет наличия поврежденных блоков, эта команда еще также проверит, соответствуют ли данные индекса данным таблицы.

Применение утилиты DBVERIFY

При возникновении подозрений в повреждении блоков данных еще можно использовать поставляемую Oracle утилиту DBVERIFY. Эта утилита запускается на уровне операционной системы. Она выполняет проверку на предмет повреждения структурной целостности файлов базы данных.

Для иллюстрации применения утилиты DBVERIFY ниже приведен пример выполнения верификации файла на платформе Windows (на платформах UNIX команда будет работать точно так же). Администратор базы данных может легко писать для выполнения верификации файлов данных специальный сценарий и затем настраивать для него график регулярного выполнения с помощью crontab. В листинге 1 показаны результаты применения утилиты DBVERIFY.

Этот пример иллюстрирует упрощенный вариант применения утилиты DBVERIFY, которая вызывается командой DBV на платформах Windows и UNIX. Ключевое слово FILE указывает, какой файл данных требуется проверить на предмет повреждения. Согласно приведенному здесь выводу, общее количество страниц, помеченных как поврежденные (Total Pages Marked Corrupt), равняется нулю, а это значит, что в базе данных нет никаких проблем со структурной целостностью.

Применение пакета DBMS_REPAIR

Несмотря на то что утилита DBVERIFY очень проста в применении, использовать ее для исправления поврежденных данных нельзя, а это является очень серьезным ограничением. Поэтому еще в версии Oracle8i появился пакет DBMS_REPAIR, позволяющий не только выявлять, но и исправлять поврежденные блоки данных без перевода файлов данных в автономный режим. Прежде чем использовать этот пакет, нужно войти в систему от имени пользователя SYS и создать две специальные таблицы: одну с приставкой repair_ и вторую с именем orphan_key.

После создания таблицы repair_table пакет DBMS_REPAIR можно запускать. В эту таблицу будет заноситься информация обо всех поврежденных данных. Выполнение содержащейся в пакете DBMS_REPAIR процедуры CHECK_OBJECT будет приводить к выявлению поврежденных блоков и отображению рекомендуемых вариантов для их исправления, а выполнение после процедуры CHECK_OBJECT запроса к таким столбцам таблицы repair_table, как OBJECT_NAME и CORRUPT_DESCRIPTION — выяснить, существуют ли повреждения в блоках данных, и если да, то какого типа.

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

Инициатива HARD

Применение RAID обеспечивает избыточность только на уровне устройств хранения данных, чтобы позволить при потере нескольких дисков не терять данные. А что если используется система с зеркальным отображением дисков, но данные, записываемые на зеркальную пару дисков, повреждены? Тогда на обоих дисках в зеркальной паре, конечно же, будут содержаться поврежденные данные. Поэтому в Oracle недавно объявили о новой инициативе для предотвращения повреждения данных еще до его возникновения, которая получила название Hardware Assisted Resilient Data (Обеспечение устойчивости данных на уровне аппаратных средств), или просто HARD. В рамках этой инициативы Oracle будет встраивать в устройства хранения, продаваемые участвующими в этой инициативе производителями, специальные алгоритмы верификации данных и тем самым предотвращать окончательную запись поврежденных данных на диск. В частности, инициатива HARD направлена на решение проблем следующего рода:

Читайте также: