|
|
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
pravednikнаш человек в гаваневопрос: почему в логе экспорта нет ни строчки про битые блоки или про то, что возникли проблемы с выгрузкой какой-то таблицы? А с чего вы взяли, что блок битый ? Наличие номера файла и блока в трейсе совсем не означает, что это битые блоки :-) По поводу 600-ой, берете первый аргумент и на металинк. да нету у меня металинка. когда-то был. не у меня. и тот - закончился..... а проблема есть: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. возникает у меня ещё один вопрос: если блок не битый, почему oracle его ищет и не может найти? т.е. почему в трейсе: Код: plsql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2012, 15:38 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
наш человек в гаваневозникает у меня ещё один вопрос: если блок не битый, почему oracle его ищет и не может найти? т.е. почему в трейсе: Читайте внимательней. Не блок, а " slot 146 not found" над своей табличкой, которую вы получили из Код: plsql 1. 2. 3. 4. Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2012, 15:49 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
pravednikнаш человек в гаваневозникает у меня ещё один вопрос: если блок не битый, почему oracle его ищет и не может найти? т.е. почему в трейсе: Читайте внимательней. Не блок, а " slot 146 not found" над своей табличкой, которую вы получили из Код: plsql 1. 2. 3. 4. Код: plsql 1. спасибо! а можно для меня чайника пояснить, что значит слот не найден? проблемы с оперативкой? и если у меня эта таблица часто используется, и она большая - 12 Гб, то стоит ли проводить analyze table tablename validate structure cascade online; при работающих пользователях? я боюсь что это может негативно сказаться на производительности? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2012, 15:53 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
можно для чайника пояснить чем отличается слот от блока? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2012, 18:18 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Столкнулся с указанной проблемой, судя по всему она возникла 4 дня назад. В логах есть ошибки: [DBD::Oracle::st execute failed: ORA-01578: разрушен блок данных ORACLE (файл # 9, блок # 3792555) ORA-01 110: файл данных 9: 'bm_index02.dbf' (DBD ERROR: OCIStmtExecute) [for Statement "..." with ParamValues: :p1='8745']]. Rolling back, giving up on account 3235 Указанный в топике запрос из dba_extents показывает, что поврежденный блок относится к индексу PER_ACCT_SERVICE_IDX. Есть бэкапы за две недели. Не посоветуете, как исправить ошибку? Пересоздать индекс? В информации по индексу указано, что distinct keys примерно 20к, rows примерно 3кк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 11:33 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
И еще, можно ли узнать, есть ли другие повреждения? В логах это единственный блок, но вдруг есть и другие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 11:39 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Alibek B.И еще, можно ли узнать, есть ли другие повреждения? Просмотрел логи бэкапов. У меня делается два бэкапа, через expdp (только таблицы) и через rman. Через expdb ошибок нет, я могу быть уверенным, что в информация в БД (содержание) не повреждена? В логах rman есть такой фрагмент: Код: plaintext 1. 2. 3. 4. 5. И непонятно, почему в логе указан файл bm_index03.dbf, если данные повреждены в файле bm_index02.dbf. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 11:50 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Поискал в alert.log, получил следующие данные: FILE_IDBLOCK_IDSEGMENT_NAMESEGMENT_TYPEFILE_NAME12412105BM_ACTION_LOGTABLEbm_data03.dbf61488857RADACCT_PKINDEXbm_index01.dbf93922567PERIODIC_ACCT_PKINDEXbm_index02.dbf93792555PER_ACCT_SERVICE_IDXINDEXbm_index02.dbf93921835DBACKUP_ACCOUNT_ID_IDXINDEXbm_index02.dbf62247489BM_ACTLOG_SERVICE_ID_IDXINDEXbm_index01.dbf2931208BM_ACTLOG_SERVICE_ID_IDXINDEXbm_index03.dbf2234187PAYMENT_ITEM_PAY_CLIENTINDEXbm_index03.dbf1517513_SYSSMU21$TYPE2 UNDOundotbs.dbf159873_SYSSMU26$TYPE2 UNDOundotbs.dbf Как я понимаю, я довольно легко отделался. В таблице BM_ACTION_LOG критичных данных нет, там вполне можно сделать skip. Для индексов можно сделать rebuild (с предварительным заданием unusable). А что делать с undo-сегментами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 12:19 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Создать новое, а старое дропнуть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 12:23 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Пересоздать — в смысле пересоздать undo-сегмент? Или к индексам это тоже относится? Среди индексов есть довольно большие, их пересоздание может быть длительным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 12:33 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Пересоздать новое UNDO-пространство (или, посмотреть, что эти экстенты в состоянии EXPIRED и забить) Ну и переключиться на него (alter system set UNDO_TABLESPACE=) Старое снести (а не выводить в OFFLINE и пугаться ошибкам в алерте) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 12:47 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Понятно, undo пересоздал. А как индексы починить не посоветуете? Допустим я хочу починить индекс PAYMENT_ITEM_PAY_CLIENT, он небольшой и не критичный для работы. Это индекс по полю PAY_CLIENT для таблицы PAYMENT_ITEM. Делаю запрос select * from PAYMENT_ITEM where PAY_CLIENT = 100, чтобы получить ошибку ORA-01578. Однако ошибки не происходит, видимо потому что для PAY_CLIENT=100 данные не повреждены. Как узнать, какие именно данные повреждены? Чтобы выполнить SQL-запрос, получить ошибку, перестроить индекс и снова выполнить SQL-запрос, убедившись что ошибка более не появляется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 12:55 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Alibek B., Если Enterprise Ed. alter index index_name rebuild online; Ну и пойти по самому страшному пути предварительно забэкапившись. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. и Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. заюзать утилитку: Код: plsql 1. потом и до начала операции посмотреть в представление и сравнить: Код: plsql 1. P.S в зависимость от типа повреждения блока лечится соответствующими методами .... в данном случае индексы самое простое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 13:07 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Ну ты же сам сказал:Alibek B.Для индексов можно сделать rebuild (с предварительным заданием unusable). PS. А таблицу, если нельзя TRUNCATE, то выполнить CTAS (с установленным SKIP) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 13:10 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Тролинalter index index_name rebuild online Видимо нет, я это уже ранее пробовал, фича online не поддерживается. Вячеслав ЛюбомудровНу ты же сам сказал Думал, может еще способы есть. У меня там парочка тяжелых индексов есть. Ок, сейчас займусь индексами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 14:24 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Сообщаю результаты. Вначале попытался было сделать перестройку индексов "на горячую", то есть на работающей БД и работающих пользователях/приложениях. По ошибке начал с индекса, который большой и очень активно используется (промахнулся при копипасте и не перепроверил). Вначале все начало тормозить, что впрочем и ожидалось. Потом начало очень сильно тормозить. Потом load average на сервере вырос до 80-100. Затем кончилась память, ядро прибило процесс oracle и зависло само. После этого я остановил клиентские подключения, перезапустил сервер, сделал перестройку индексов на свободной базе (на удивление быстро, индекс на 60 миллионов строк перестроился буквально минут за 6), после чего стартовал клиентские приложения. Вообщем так и надо было делать с самого начала, но я надеялся, что Oracle сам как-то разрулит системные ресурсы. Можно ли теперь сделать проверку БД, чтобы убедиться, что все повреждения исправлены? Это нужно сделать задание с командой VALIDATE для rman, как написали парой постов выше? (утилиты dbv у меня нет и как я понял, ее используют на остановленной БД) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2018, 16:12 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Утилиту dbverify я все же нашел. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. Или dbv не все проверяет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.06.2018, 19:39 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Alibek B., Забэкапиться и сделать то что я написал. Предварительно посмотрев в select * from V$DATABASE_BLOCK_CORRUPTION и после всех операций в select * from V$DATABASE_BLOCK_CORRUPTION тогда можно быть уверенным что все "хокей" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.06.2018, 10:37 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
В таблице V$DATABASE_BLOCK_CORRUPTION есть четыре строчки, все принадлежат одному файлу (файл используется для индексов). Утилита dbv показывает такие же данные. При запуске бэкапа через rman (при заранее выставленном maxcorrupt=4) бэкап выполняется, в alert.log для этих четырех блоков появляются соответствующие сообщения. Но при этом в dba_extents за этими блоками не числятся никакие объекты. Разве такое может быть? И как исправлять эту ошибку, если нет объекта, использующего эти блоки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2018, 13:26 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Разместить в этих блоках новый объект ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2018, 13:33 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
А как это можно сделать? В синтаксисе DDL я не могу понять, как задать, в каких блоках будет размещаться объект. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2018, 13:49 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
А ты просто выделяй экстенты в нужном файле, авось и попадешь в нужный блок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2018, 13:58 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Сделал пустую таблицу. С помощью alter table allocate extent расширял ее, пока не попал на нужные блоки. После этого выполнил команду analyze table validate structure. Команда выполнилась успешно, ни про какие ошибки ничего не сообщила. Затем я дропнул таблицу и снова запустил dbv. И снова получил те же ошибочные блоки, что были ранее. Что я делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2018, 14:24 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
Что ж ты не сказал/акцентировал, что у тебя 10-ка Там v$database_block_corruption заполняется только при BACKUP VALIDATE/CHECK LOGICAL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2018, 14:52 |
|
||
|
ORA-01578: ORACLE data block corrupted
|
|||
|---|---|---|---|
|
#18+
А на что это влияет? Список коррумпированных блоков у меня есть, я его получаю либо после проверки через dbverify, либо после бэкапа с помощью rman. Мне непонятно, как эти блоки исправить. Допустим у меня есть таблица tmp2, которая гарантированно размещается на поврежденных блоках. Видимо мне нужно использовать DBMS_REPAIR, но не могу понять, каким образом. Я делаю CHECK_OBJECT (чтобы пометить блоки), затем FIX_CORRUPT_BLOCKS, затем дропаю таблицу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2018, 15:39 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39667634&tid=1883263]: |
0ms |
get settings: |
5ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
142ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 424ms |

| 0 / 0 |
