April 30, 2021
I got ” ORA-01114: IO error writing block to file string (block # string) ” error in Oracle database.
ORA-01114: IO error writing block to file string (block # string)
Details of error are as follows.
ORA-01114: IO error writing block to file string (block # string) Cause: The device on which the file resides is probably offline. If the file is a temporary file, then it is also possible that the device has run out of space. This could happen because disk space of temporary files is not necessarily allocated at file creation time. Action: Restore access to the device or remove unnecessary files to free up space.
IO error writing block to file string (block # string)
This ORA-01114 errors are related with the Temp file Header of one of the Temporary Tablespace files is corrupted.
SELECT * FROM V$TEMP_SPACE_HEADER; TABLESPACE_NAME FILE_ID BYTES_USED BLOCKS_USED BYTES_FREE BLOCKS_FREE RELATIVE_FNO TEMP 4 -9,641,656,320 -1,176,960 17,157,849,088 2,094,464 3 <<<<<<<< -ve (Negative) Values in BYTES_USED & BLOCKS_USED indicates Tempfile Header Corruption TEMP 5 7,516,192,768 917,504 0 0 4 TEMP 1 6,262,095,872 764,416 180,355,072 22,016 1 TEMP 3 6,442,450,944 786,432 0 0 2
In the V$TEMP_SPACE_HEADER, there are negative values for some of the columns indicates that the temp file header have been corrupted and so when application is trying to access these corrupt header might have got the error ” ORA-01114 error writing block to file” at Application Logs/Screen.
Action plan to fix:
Please drop/delete this temp file (example in our case: FILE_ID 4 ) and create new temp file to resolve the issue. ( Please check the output of SELECT * FROM V$TEMP_SPACE_HEADER; from all the Nodes and drop or delete and create new temp files if any -ve values are seen for any columns )
Example/syntax:
SQL> ALTER DATABASE TEMPFILE '/<path>/temp04.dbf' DROP INCLUDING DATAFILES; Database altered. SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/<path>/temp04.dbf' SIZE 7G; Tablespace altered. SQL> SELECT * FROM V$TEMP_SPACE_HEADER; TABLESPACE_NAME FILE_ID BYTES_USED BLOCKS_USED BYTES_FREE ------------------------------ ---------- ---------- ----------- ---------- BLOCKS_FREE RELATIVE_FNO ----------- ------------ TEMP 1 6215958528 758784 226492416 27648 1 TEMP 2 1048576 128 7515144192 917376 3 TEMP 3 6442450944 786432 0 0 2 TEMP 5 7516192768 917504 0 0 4
Or Restore access to the device or remove unnecessary files to free up space.
Do you want to learn Oracle Database for Beginners, then read the following articles.
Oracle Tutorial | Oracle Database Tutorials for Beginners ( Junior Oracle DBA )
1,157 views last month, 1 views today
About Mehmet Salih Deveci
I am Founder of SysDBASoft IT and IT Tutorial and Certified Expert about Oracle & SQL Server database, Goldengate, Exadata Machine, Oracle Database Appliance administrator with 10+years experience.I have OCA, OCP, OCE RAC Expert Certificates I have worked 100+ Banking, Insurance, Finance, Telco and etc. clients as a Consultant, Insource or Outsource.I have done 200+ Operations in this clients such as Exadata Installation & PoC & Migration & Upgrade, Oracle & SQL Server Database Upgrade, Oracle RAC Installation, SQL Server AlwaysOn Installation, Database Migration, Disaster Recovery, Backup Restore, Performance Tuning, Periodic Healthchecks.I have done 2000+ Table replication with Goldengate or SQL Server Replication tool for DWH Databases in many clients.If you need Oracle DBA, SQL Server DBA, APPS DBA, Exadata, Goldengate, EBS Consultancy and Training you can send my email adress [email protected].- -Oracle DBA, SQL Server DBA, APPS DBA, Exadata, Goldengate, EBS ve linux Danışmanlık ve Eğitim için [email protected] a mail atabilirsiniz.
Whilst creating a new 10GB index on a large 40GB table I was experiencing the
“ORA-01114: IO error writing block to file <file#> (block # <block#>)” error.
The main vital piece of information is the file number (<file#>). This can be found in the DBA_DATA_FILES or DBA_TEMP_FILES views as the FILE_ID column.
So, you construct a query to go find the file name:
SELECT file_id, file_name
FROM dba_data_files
WHERE file_id = <the number>
UNION ALL
SELECT file_id, file_name
FROM dba_temp_files
WHERE file_id = <the number>;
NOTE: I query both just in case. I’ve worked on systems where the TEMP tablespace has not been created as “TEMPORARY”!
After running the query, you get “0 rows returned”.
What!
Well, in this case, the TEMP tablespace was a proper TEMPORARY tablespace as the file_id was returned from the DBA_TEMP_FILES view.
I knew that the file numbers were somehow linked to the number of permitted files in the database. This is controlled by the DB_FILES database parameter.
Looking at the Oracle documentation (for 10g) here: https://docs.oracle.com/cd/B19306_01/server.102/b14231/dfiles.htm#i1206149
You will see that Oracle states that:
“…the DB_FILES initialization parameter indicates the amount of SGA space to reserve for datafile information and thus, the maximum number of datafiles that can be created for the instance.”
In short this means that the DB_FILES parameter only applies to datafiles and not tempfiles.
Therefore, all other files will be outside this parameter range.
My parameter DB_FILES was set to 1024.
My reported file# in the ORA-01114 error was greater than 1024.
If you look at the file_id values for the DBA_TEMP_FILES view, you’ll notice that the file_id numbers conflict with the file_id values in DBA_DATA_FILES.
Since the tempfiles exist outside the range of DB_FILES, I subtracted the value of parameter “DB_FILES” from the reported file#, to achieve the file_id for tempfiles belonging to temporary tablespaces.
Voila!
Sure enough, when I subtracted 1024 (my DB_FILES value) from my reported file id in the ORA-01114, I got 2, which equated to the second tempfile in the TEMP tablespace.
The partition that the tempfile was sitting in was 95% full, but the tempfile couldn’t expand by the requested next extent size as it would be more than the partition free space. Increasing the partition size fixed my problem.
Is there another way of viewing the online file# vs the DBA_x_FILES file_id field? I don’t know, but if I find one, I’ll post it here.
█ 08.05.2007 10:04
Посмотрела по форуму — не нашла решения. Помогите кто может. Второй день не стартует база вчера на один индексный файл ругалась сегодня на второй. Причем файлы вчерашний и сегодняшний лежат на разных физических дисках.
Errors in file c:ORACLEadminyablcobdumpyablcoLGWR.TRC:
ORA-01110: data file 32: ‘E:ORACLEORADATAYABLCOINDX14.DBF’
ORA-01114: IO error writing block to file 32 (block # 1)
ORA-27072: skgfdisp: I/O error
OSD-04008: Writefile(),
O/S-Error: (OS 5) .
После recover база стартует, но может кто поможет советом почему происходит так. Кая я поняла это ошибка
Message
ORA-01114:IO error writing block to file string (block # string)
Cause
The device on which the file resides is probably off line.
Action
Restore access to the device, then retry the operation.
и виноваты диски на сервере. Подскажите — ошибка связана только с железом или может это побочный эффект какого то ораклового процесса?
█ 08.05.2007 10:06
Вряд ли побочный эффект, скорее всего пора махать платочком своим винтам…
█ 08.05.2007 10:21
Цитата:
inna ➤ Олег не пугай так….
Да я как есть говорю… Там же написано, «верни девайс на место», т.е. произошел таймаут при записи на него. Как правило, либо посыпался круто, либо электроника дохнет. Причем то, что такие ошибки появились — признак того, что база твоя уже побитая и срочно нужно обложиться бекапами разных мастей и беречь старые.
█ 08.05.2007 10:34
За совет спасибо. Серваку полгода, брали фирменный HP. А не может быть что нибудь со скази там например контроллером или с зеркалом там какая настройка неправильная? Просто в железе честно лох, если не трудно в двух словах — не может это проблема быть не в физическом повреждении жесткого диска?
█ 08.05.2007 10:40
Да если честно, сложно придумать что-либо такое, что могло бы не тормозить, а так выбивать диски… Контроллер может глючить, но тоже вряд ли, что из-за настроек…
█ 08.05.2007 10:42
Вообще, если на разных винтах ошибки, то я бы еще и мать вдобавок поменял бы на всяк случай. У меня встречались проблемы с IDE и SATA на мамках. Ну если брендовому серваку полгода, то срочно отдавать обратно на тестирование в контору, где брали.
█ 08.05.2007 11:08
inna, а в системных виндовых логах есть какие ошибки?
█ 08.05.2007 11:18
в системных логах ничего нет — служба запущена, служба остановлена. А второй день одинаковая картинка — бекапер базу останавливает и потом она не стартует с такой ошибкой.
█ 08.05.2007 11:28
Цитата:
inna ➤ За совет спасибо. Серваку полгода, брали фирменный HP. А не может быть что нибудь со скази там например контроллером или с зеркалом там какая настройка неправильная? Просто в железе честно лох, если не трудно в двух словах — не может это проблема быть не в физическом повреждении жесткого диска?
У HP куча собственных утилиток по железу. Поставить и посмотреть, на что ругается.
У нас база дико тормозила из-за батарейки, из-за ее низкого заряда просто снижалась скорость обмена с дисками на контроллере.
Часовой пояс GMT +3, время: 01:42.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.