Dbverify oracle как запустить

Обновлено: 07.07.2024

Часовой пояс: UTC + 3 часа

Правила форума

ВНИМАНИЕ! Прежде чем задавать вопрос, ознакомьтесь со ссылками ниже:

Вопросы по отличиям версий SAP, Add-On, EHP - сюда
Вопросы по SAP Front End (SAPlogon, SAPgui, guiXT и т.д.) - сюда
Вопросы по LSMW - сюда
Вопросы по архивации в SAP - сюда
Вопросы по SAP GRC - сюда
Вопросы по SAP Business Workplace (почте SAP) и SAP Office - сюда
Вопросы по miniSAP (SAP mini basis) - сюда
Вопросы по SAP HANA - сюда
Вопросы по лицензированию продуктов SAP - сюда

ORA-01578: ORACLE data block corrupted

ОС - HP-UX , БД - Oracle 9

последняя проверка была успешной 6.02

Нота 365481 поможет идентифицировать объект, который принадлежит поврежденному блоку. Дальнейшие действия будут зависеть от типа объекта (таблица, индекс, сегмент отката. ).

Пометил блоки чтобы не использовались

dev:oradev 6> dbv file=/oracle/DEV/sapdata1/dev_10/dev.data10 blocksize=8192

DBVERIFY: Release 9.2.0.7.0 - Production on Tue Feb 19 13:33:25 2008

DBVERIFY - Verification starting : FILE = /oracle/DEV/sapdata1/dev_10/dev.data10
Page 208009 is marked corrupt
***
Corrupt block relative dba: 0x06032c89 (file 24, block 208009)
Bad header found during dbv:
Data in bad block -
type: 11 format: 2 rdba: 0x05400001
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x04
consistency value in tail: 0x00000b01
check value in block header: 0x946, computed block checksum: 0x0
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

Page 208257 is marked corrupt
***
Corrupt block relative dba: 0x06032d81 (file 24, block 208257)
Bad header found during dbv:
Data in bad block -
type: 11 format: 2 rdba: 0x03c00001
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x04
consistency value in tail: 0x00000b01
check value in block header: 0x51b, computed block checksum: 0x0
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

Page 361580 is marked corrupt
***
Corrupt block relative dba: 0x0605846c (file 24, block 361580)
Bad header found during dbv:
Data in bad block -
type: 6 format: 2 rdba: 0x03c256ec
last change scn: 0x0000.060ba1b5 seq: 0x1 flg: 0x06
consistency value in tail: 0xa1b50601
check value in block header: 0x3fc6, computed block checksum: 0x0
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

показывает таблицы и индексы которые надо востановить или перестроить , вот кусок

SQL> SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME FROM DBA_EXTENTS
2 WHERE FILE_ID = 24 AND 208009 BETWEEN BLOCK_ID AND (BLOCK_ID+BLOCKS -1);

SQL> SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME FROM DBA_EXTENTS
2 WHERE FILE_ID = 24 AND 208257 BETWEEN BLOCK_ID AND (BLOCK_ID+BLOCKS -1);

SQL> SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME FROM DBA_EXTENTS
2 WHERE FILE_ID = 24 AND 361580 BETWEEN BLOCK_ID AND (BLOCK_ID+BLOCKS -1);

Подскажите как проще это сделать ( не очень силён в Oracle )

0 проще - удалить и пересоздать.
А вот по таблицам нужно будет прогнать 'аnalyze table . validate structure cascade online;' и с результатом проверки к пункту 7 ноты 365481.
Удачи.

Часть таблиц проходит нормально , запускаю alter
но когда потом запускаю DBVERIFY блок всё равно в файле Corrupt

SQL> analyze table sapdev.moni validate structure cascade online;

SQL> alter table sapdev.moni deallocate unused;

dbv file=/oracle/DEV/sapdata1/dev_10/dev.data10 blocksize=8192

DBVERIFY: Release 9.2.0.7.0 - Production on Tue Feb 26 17:07:27 2008

Часть показывает при анализе с ошибками

не совсем разобрался что прописать из пункта 7 ноты 365481.

a) dbverify without errors/analyze without errors
You probably do not have a corruption. Repeat the access that indicated the corruption. If this is successful this time AND if you can read the table using a
select * from sapr3."<TABLE>";
AND if none of the procedures described in Note 23345 reports a problem, it is very likely that a temporary corruption existed in the memory but not on the hard disk. The block (which was only corrupt in the main memory) was not reimported to the hard disk because it was not changed. Always check your hardware in this case. Note 786645 contains additional reasons for temporary corruption.
b) dbverify with errors/analyze without errors
The corruption is probably located in a block of the table that has never contained data. Execute the following command:
alter table <tablename> deallocate unused;
The corruption should then appear in the free space and should therefore be deleted as described there.
Furthermore, in tables with LOB columns, the corruption may be located in the lob segment. The analysis is not capable of recognizing this type of corruption. In this case, proceed as described under "dbverify with errors/analyze with errors".
c) dbverify with errors/analyze with errors
Save the corrupt data file and transfer a backup of this file from a backup that does not contain the corruption. Recover this file up to the current time.
If you do not have a backup that you can definitely say does not contain the corruption, you can restore a file from a backup that is still available in A DIRECTORY THAT DOES NOT BELONG TO THE DB and check this backup using dbv. If a corruption is not reported, you have subsequently verified your backup because, on the one hand, dbverify can recognize the corruption and, on the other, your backup does not have any corruptions.
To import a file back into another directory using brrestore, use the following command:

Abstract:
brrestore -b <log> -m <number of file>=<Restore Directory>

Повреждение блоков

Поврежденный блок данных (corrupted data block) - это блок, содержимое которого не распознается на основе формата Oracle или его содержимое внутренне несогласованно. Обычно повреждения вызываются сбоями аппаратуры или проблемами операционной системы.

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

При логическом повреждении возникает внутренняя ошибка Oracle. Блоки помечаются базой данных как логически поврежденные (logically corrupt) после обнаружения их несогласованности.

Если искажение блока вызвано повреждением носителя (media corrupt), тогда нет смысла читать информация блока с диска.

Симптомы: ORA-1578

Обычно ошибка ORA-1578 возникает в результате аппаратных проблем.

Ошибка ORA-1578, постоянно возвращаемая с одними и теми же параметрами, почти
всегда означает искажение блока на носителе.

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

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

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

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

Как обнаруживать и устранять влияние повреждений (продолжение)

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

Возможные типы аппаратных сбоев:

отказ аппаратуры или программно-аппаратных средств ввода-вывода;
проблемы, связанные с кэшем и подсистемой ввода-вывода операционной системы;
проблемы памяти и страничного обмена;
ошибочное выполнение утилит восстановления после дисковых сбоев (disk repair utilities).

Функциональные возможности, имеющие отношение к обнаружению и устранению повреждений

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

Утилита DBVERIFY

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

Ограничения использования утилиты DBVERIFY:

DBVERIFY не выявляет проблемы несоответствия индексов и таблиц, которые могут быть обнаружены ПО команде

DBVERIFY не проверяет ни оперативные журналы, ни управляющие файлы.
DBVERIFY проверяет блоки только изолированно, она не выясняет, является ли блок частью существующего объекта или нет.
Для "чистых" устройств (raw devices, "чистых" дисковых секций) необходимо задавать параметр END, чтобы устранить просмотр блоков, размещенных за границей пространства файла данных:

Интерпретация выходных данных утилиты DBVERIFY

"Плывущие блоки" (influx blocks) - это расщепленные блоки (split blocks). Утилита DBVERIFY не определяет такой блок как поврежденный, так как во время первого чтения процесс DBWn писал новую версию этого блока и при проверке были прочитаны новая и старая части блока. DBVERIFY обнаруживает только логические повреждения. Поэтому возможно появление искаженных блоков выше отметки максимального заполнения (high-water mark).

Пример использования утилиты DBVERIFY:

Команда ANALYZE

Команда ANALYZE используется для проверки структуры таблицы или секций таблицы, а также индекса или индексных секций. Анализируемый объект должен быть локальным и находиться в собственной схеме пользователя, выполняющего команду, либо пользователь должен иметь системную привилегию ANALYZE ANY. Если задан параметр CASCADE, выполняется проверка указанного объекта и всех связанных с ним объектов.

Такую команду можно запускать несколько раз в сеансе SQL*Plus с параметром CASCADE, чтобы выяснить, постоянно ли при этом обнаруживаются ошибки целостности данных.

Для секционированных таблиц команда ANALYZE также проверяет принадлежность строки к соответствующей секции.Значение ROWID неверно расположенной строки заносится в таблицу INVALID_ROWS.

SQL> ANALYZE TABLE секционированная_таблица PARTITION (pi)
2 VALIDATE STRUCTURE INTO invalid__rows;

Простая команда выбора (SELECT * FROM table) полностью просматривает таблицу, читая все блоки до отметки максимального заполнения. Такую команду можно использовать для быстрой проверки наличия повреждений в текущих данных таблицы.

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

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

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

После этого нужно запустить полученные команды в командной оболочке (cmd.exe).

В полученных текстовых файлах вы можете увидеть результаты диагностики. Информация об испорченных блоках может быть представлена в виде Data Block Address (DBA).

DBVERIFY - Verification starting : FILE = C:\ORACLE\PRODUCT\10.2.0\ORADATA\EAO\INDX05.DBF
Block Checking: DBA = 58789211 , Block Type = KTB-managed data block
**** row 105: key out of order
---- end index block validation
Page 68955 failed with check code 6401

В этом случае нужно перевести DBA в номер блока и номер файла с помощью запроса

2) Определить объект в котором содержаться испорченные блоки и его тип

Для определения объекта и его типа, нужно выполнить запрос (здесь понадобятся номер файла и номер блока):

После того как объект выявлен, можно попробовать восстановить его. Методы восстановления различных типов объектов можно посмотреть в статье Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g [ID 28814.1]. Обычно, проще всего с индексами, если сама таблица не испорчена то их можно просто удалить и создать заново.

ПРИМЕЧАНИЕ 1 : Даже если обнаружился всего один испорченный блок, лучше проверить все файлы БД на предмет наличия испорченных блоков, т.к. такие блоки обнаруживаются только в момент обращения к ним.

Запрос (выполнять под SYS) для получения набора команд, которые необходимо выполнить в CMD. В результате выполнения в папке где лежать файлы БД получаться файлы *.txt с результатами проверки.

ПРИМЕЧАНИЕ 2 : Начиная примерно с 10.2.0.5 в alert.log пишется сразу информация об объекте в котором выявлен испорченный блок, что очень удобно. Выглядит это так

Mon Apr 09 10:49:21 Ekaterinburg Daylight Time 2012
Hex dump of (file 4, block 3116391) in trace file c:oracleproduct10.2.0adminssdbdumpssd_s002_3252.trc
Corrupt block relative dba: 0x002f8d67 (file 4, block 3116391)
Fractured block found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x002f8d67
last change scn: 0x0000.001c3a89 seq: 0x3 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xac160601
check value in block header: 0xbda5
computed block checksum: 0x969d
Reread of rdba: 0x002f8d67 (file 4, block 3116391) found same corrupted data
Mon Apr 09 10:49:21 Ekaterinburg Daylight Time 2012
Corrupt Block Found
TSN = 4, TSNAME = INDX
RFN = 1024, BLK = 3116391, RDBA = 3116391
OBJN = 45280, OBJD = 45280, OBJECT = RT_RE_FK_I, SUBOBJECT =
SEGMENT OWNER = REG_RT, SEGMENT TYPE = Index Segment

ПРИМЕЧАНИЕ 3 : Если база работает в archivelog и есть резервные копии сделанные с помощью RMAN. Можно восстановить испорченные блоки с помощью RMAN.

Master Note for Handling Oracle Database Corruption Issues [ID 1088018.1]
Статья дает глобальное представление о повреждениях БД и необходимых действиях в зависимости где это повреждение обнаружено.
Это практически карта на которой отображены все статьи по corruption.

Physical and Logical Block Corruptions. All you wanted to know about it. [ID 840978.1]
Объясняет причины логических и физических повреждений.
Интересно почитать для общего развития.

Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g [ID 28814.1]
Описывает как определить поврежденный объект и что делать с каждым конкретным типом объектов.
Запись ORA-01578 ORACLE data block corrupted впервые появилась Dmitry Bobrovsky Blog

Регулярное создание резервных копий производственной базы данных 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 направлена на решение проблем следующего рода:

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

C:\Users\XIFENFEI>D:\app\XIFENFEI\product\11.2.0.1\dbhome_2\bin\sqlplus / as sys

SQL * Plus: Release 11.2.0.1.0 производства на 12 марта 15:04:32 2020

ORA-01075: Вы вошли в систему

Пожалуйста, введите имя пользователя:

ORA-01017: Имя пользователя / пароль неверен; Войти отвергается

Пожалуйста, введите имя пользователя:

ORA-01017: Имя пользователя / пароль неверен; Войти отвергается

SP2-0157: Не удается подключиться к Oracle после 3 попыток, выход SQL * Plus

Анализируя ошибку при запуске базы данных (не нормально открытый успех)

C:\Users\XIFENFEI>D:\app\XIFENFEI\product\11.2.0.1\dbhome_2\bin\sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Четверг 12 марта 2020 14:58:28

Простаивает рутина подключена.

SQL> startup mount pfile= 'F:\pfile.txt' ;

были начаты процедуры Oracle.

Total System Global Area 3307048960 bytes

Fixed Size 2180264 bytes

Variable Size 1811942232 bytes

Database Buffers 1476395008 bytes

Redo Buffers 16531456 bytes

База данных загружается.

SQL> alter database open ;

alter database open

Ошибки в цепи 1:

ORA-00604: Получение SQL Уровень 1 ошибка

ORA-01578: Oracle повреждение блока данных (номер файл 1, блок номер 48396)

ORA-01110: файл данных 1: 'F:\ORADATA\SYSTEM01.DBF'

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

DBVERIFY: Выпуск 11.2.0.1.0 - Производство на 12 марта 19:12:34 2020

DBVERIFY - Начало проверки: Файл = F: \ ORADATA \ System01.dbf

Corrupt block relative dba: 0x0040bbc0 ( file 1, block 48064)

Fractured block found during dbv:

Data in bad block:

type : 6 format : 2 rdba: 0x0040bbc0

last change scn: 0x0000.0006f69c seq : 0x1 flg: 0x06

spare1: 0x0 spare2: 0x0 spare3: 0x0

consistency value in tail : 0x43455474

check value in block header: 0x3893

computed block checksum: 0xadfa

Corrupt block relative dba: 0x0040bd1c ( file 1, block 48412)

Bad header found during dbv:

Data in bad block:

type : 36 format : 2 rdba: 0x6dce856d

last change scn: 0xfc44.d24c936f seq : 0xdc flg: 0x3b

spare1: 0x9c spare2: 0x92 spare3: 0xcf67

consistency value in tail : 0x43455474

check value in block header: 0x2598

block checksum disabled

DBVERIFY - Проверка Завершение

Проверить страницу Всего: 249600

Общее количество страниц (данные): 209467

Сбой страницы Общее количество (данные): 0

Общее количество страниц обработки (индекс): 13616

Неудача страница Total (индекс): 0

Общее количество страниц обработки (другие): 3369

Обработанная общая страница (сегмент): 1

Неудача верхнее число (сегмент): 0

Пустая страница Всего: 22799

Общее количество маркировок, помеченные как поврежденные: 349

Общее количество притоков: 1

Количество зашифрованных страниц: 0

Самый высокий блок SCN: 84123103 (0.84123103)

Информация о журнале оповещения базы данных

Thu Mar 12 14:52:20 2020

SMON: enabling cache recovery

Successfully onlined Undo Tablespace 2.

Verifying file header compatibility for 11g tablespace encryption..

Verifying 11g file header compatibility for tablespace encryption completed

SMON: enabling tx recovery

Database Characterset is ZHS16GBK

Hex dump of ( file 1, block 48403) in trace file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc

Corrupt block relative dba: 0x0040bd13 ( file 1, block 48403)

Bad header found during multiblock buffer read

Data in bad block:

type : 36 format : 2 rdba: 0x6dce856d

last change scn: 0xfc44.d24c936f seq : 0xdc flg: 0x3b

spare1: 0x9c spare2: 0x92 spare3: 0xcf67

consistency value in tail : 0x43455474

check value in block header: 0x2598

block checksum disabled

Reading datafile 'F:\ORADATA\SYSTEM01.DBF' for corruption at rdba: 0x0040bd13 ( file 1, block 48403)

Reread ( file 1, block 48403) found same corrupt data

Hex dump of ( file 1, block 48404) in trace file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc

Corrupt block relative dba: 0x0040bd14 ( file 1, block 48404)

Corrupt Block Found

Bad header found during multiblock buffer read

TSN = 0, TSNAME = SYSTEM

Data in bad block:

RFN = 1, BLK = 48403, RDBA = 4242707

type : 36 format : 2 rdba: 0x6dce856d

last change scn: 0xfc44.d24c936f seq : 0xdc flg: 0x3b

spare1: 0x9c spare2: 0x92 spare3: 0xcf67

consistency value in tail : 0x43455474

check value in block header: 0x2598

block checksum disabled

Reading datafile 'F:\ORADATA\SYSTEM01.DBF' for corruption at rdba: 0x0040bd14 ( file 1, block 48404)

Reread ( file 1, block 48404) found same corrupt data

Errors in file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc (incident=3784):

ORA-01578: Oracle повреждение блока данных (номер файл 1, блок номер 48404)

ORA-01110: файл данных 1: 'F:\ORADATA\SYSTEM01.DBF'

Incident details in : d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\incident\incdir_3784\o11201gbk_ora_9480_i3784.trc

OBJN = 36, OBJD = 36, OBJECT = I_OBJ1, SUBOBJECT =

SEGMENT OWNER = SYS, SEGMENT TYPE = Index Segment

Corrupt Block Found

TSN = 0, TSNAME = SYSTEM

RFN = 1, BLK = 48404, RDBA = 4242708

OBJN = 36, OBJD = 36, OBJECT = I_OBJ1, SUBOBJECT =

SEGMENT OWNER = SYS, SEGMENT TYPE = Index Segment

Errors in file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc:

ORA-00604: Получение SQL Уровень 1 ошибка

ORA-01578: Oracle повреждение блока данных (номер файл 1, блок номер 48404)

ORA-01110: файл данных 1: 'F:\ORADATA\SYSTEM01.DBF'

Errors in file d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc:

ORA-00604: Получение SQL Уровень 1 ошибка

ORA-01578: Oracle повреждение блока данных (номер файл 1, блок номер 48404)

ORA-01110: файл данных 1: 'F:\ORADATA\SYSTEM01.DBF'

Error 604 happened during db open , shutting down database

USER (ospid: 9480): terminating the instance due to error 604

Это можно увидеть здесь, что база данных не может быть запущена, как правило, в основном потому, что i_obj1 (INDEX из $ таблицы OBJ) просто поврежден, в результате чего база данных, которая не может быть, а анализ определяется следующими результатами SQL в неудаче.

Dump continued from file : d:\app\xifenfei\diag\rdbms\qdbdc\o11201gbk\trace\o11201gbk_ora_9480.trc

ORA-01578: Oracle повреждение блока данных (номер файл 1, блок номер 48404)

ORA-01110: файл данных 1: 'F:\ORADATA\SYSTEM01.DBF'

========= Dump for incident 3784 (ORA 1578) ========

dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

----- Current SQL Statement for this session (sql_id=cq514nkrp38hv) -----

Ремонт поврежденного блока i_obj1, база данных инициируются успешно

C:\Users\XIFENFEI>D:\app\XIFENFEI\product\11.2.0.1\dbhome_2\bin\sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Четверг 12 марта 2020 15:05:48

Простаивает рутина подключена.

SQL> startup pfile= 'f:/pfile.txt' mount;

были начаты процедуры Oracle.

Total System Global Area 3307048960 bytes

Fixed Size 2180264 bytes

Variable Size 1811942232 bytes

Database Buffers 1476395008 bytes

Redo Buffers 16531456 bytes

База данных загружается.

SQL> alter database open ;

База данных была изменена.

Попробуйте экспортировать данные

C:\Windows\system32>exp system /oracle owner=gis_sys file =f: /gis_sys .dmp FEEDBACK

=10000 COMPRESS=NO BUFFER=102400000 STATISTICS=none

Экспорт: Release 11.2.0.1.0 - Производство в четверг 12 марта 15:46:19 2020

Подключение: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Вывезенный набор символов zhs16GBK и набор символов AL16UTF16 NCHAR

Назначенный пользователь собирается экспортировать .

Экспорт предварительной схема объекты процесса и операции

Экспорт внешней функции библиотеки для gis_sys пользователей

Тип экспорта PUBLIC синоним

Exp-00008: встреча Oracle ошибка 604

ORA-00604: Получение SQL Уровень 1 ошибка

ORA-01410: Invalid RowID

Exp-00000: Отказ конца Экспорт

Файл Анализ трассировки

*** SESSION ID:(192.3) 2020-03-12 15:05:36.132

OBJD MISMATCH typ=6, seg.obj=18, diskobj=224, dsflg=100100, dsobj=18, tid=18, cls=1

ORA-00604: Получение SQL Уровень 1 ошибка

ORA-01410: Invalid RowID

ORA-00604: Получение SQL Уровень 1 ошибка

ORA-01410: Invalid RowID

Поскольку идентификатор OBJ - 18 (OBJ $), блок, хранящийся в соответствующей базе данных, не совпадает, нет совпадения, так что ошибка происходит, по анализу, поскольку ошибка записи I_OBJ1 вызывает проблему, исправляя после записи, Данные идеально экспортируются.

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