After hours of misdirection from official Oracle support, I dove into this on my own and fixed it. I am documenting it here in case someone else has this problem.
To do any of this, you must be the oracle user:
$ su - oracle
Step 1: You need to look at the alert log. It isn’t in /var/log as expected. You have to run an Oracle log reading program:
$ adrci
ADRCI: Release 11.2.0.1.0 - Production on Wed Sep 11 18:27:56 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
ADR base = "/u01/app/oracle"
adrci>
Notice the ADR base. That is not the install. You need to see the homes so you can connect to the one that you use.
adrci> show homes
ADR Homes:
diag/rdbms/cci/CCI
diag/tnslsnr/cci/listener
diag/tnslsnr/cci/start
diag/tnslsnr/cci/reload
CCI is the home. Set that.
adrci> set home diag/rdbms/cci/CCI
adrci>
Now, you can look at the alert logs. It would be very nice if they were in /var/log so you could easily parse the logs. Just stop wanting and deal with this interface. At least you can tail (and I hope you have a scrollback buffer):
adrci> show alert -tail 100
Scroll back until you see errors. You want the FIRST error. Any errors after the first error are likely being caused by the first error. In my case, the first error was:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 100.00% used, and has 0 remaining bytes available.
This is caused by transactions. Oracle is not designed to be used. If you do push a lot of data into it, it saves transaction logs. Those go into the recovery file area. Once that is full (50GB full in this case). Then, Oracle just dies. By design, if anything is messed up, Oracle will respond by shutting down.
There are two solutions, the proper one and the quick and dirty one. The quick and dirty one is to increase db_recovery_file_dest_size. First, exit adrci.
adrci> exit
Now, go into sqlplus without opening the database, just mounting it (you may be able to do this without mounting the database, but I mount it anyway).
$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Wed Sep 11 18:40:25 2013
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> connect / as sysdba
Connected.
SQL> startup mount
Now, you can increase your current db_recovery_file_dest_size, increased to 75G in my case:
SQL> alter system set db_recovery_file_dest_size = 75G scope=both
Now, you can shutdown and startup again and that previous error should be gone.
The proper fix is to get rid of the recovery files. You do that using RMAN, not SQLPLUS or ADRCI.
$ rman
Recovery Manager: Release 11.2.0.1.0 - Production on Wed Sep 11 18:45:11 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
RMAN> backup archivelog all delete input;
If you’ve got RMAN-06171: not connected to target database, than try to use rman target / instead of just rman
Wait a long time and your archivelog (that was using up all that space) will be gone. So, you can shutdown/startup your database and be back in business.
After hours of misdirection from official Oracle support, I dove into this on my own and fixed it. I am documenting it here in case someone else has this problem.
To do any of this, you must be the oracle user:
$ su - oracle
Step 1: You need to look at the alert log. It isn’t in /var/log as expected. You have to run an Oracle log reading program:
$ adrci
ADRCI: Release 11.2.0.1.0 - Production on Wed Sep 11 18:27:56 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
ADR base = "/u01/app/oracle"
adrci>
Notice the ADR base. That is not the install. You need to see the homes so you can connect to the one that you use.
adrci> show homes
ADR Homes:
diag/rdbms/cci/CCI
diag/tnslsnr/cci/listener
diag/tnslsnr/cci/start
diag/tnslsnr/cci/reload
CCI is the home. Set that.
adrci> set home diag/rdbms/cci/CCI
adrci>
Now, you can look at the alert logs. It would be very nice if they were in /var/log so you could easily parse the logs. Just stop wanting and deal with this interface. At least you can tail (and I hope you have a scrollback buffer):
adrci> show alert -tail 100
Scroll back until you see errors. You want the FIRST error. Any errors after the first error are likely being caused by the first error. In my case, the first error was:
ORA-19815: WARNING: db_recovery_file_dest_size of 53687091200 bytes is 100.00% used, and has 0 remaining bytes available.
This is caused by transactions. Oracle is not designed to be used. If you do push a lot of data into it, it saves transaction logs. Those go into the recovery file area. Once that is full (50GB full in this case). Then, Oracle just dies. By design, if anything is messed up, Oracle will respond by shutting down.
There are two solutions, the proper one and the quick and dirty one. The quick and dirty one is to increase db_recovery_file_dest_size. First, exit adrci.
adrci> exit
Now, go into sqlplus without opening the database, just mounting it (you may be able to do this without mounting the database, but I mount it anyway).
$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Wed Sep 11 18:40:25 2013
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> connect / as sysdba
Connected.
SQL> startup mount
Now, you can increase your current db_recovery_file_dest_size, increased to 75G in my case:
SQL> alter system set db_recovery_file_dest_size = 75G scope=both
Now, you can shutdown and startup again and that previous error should be gone.
The proper fix is to get rid of the recovery files. You do that using RMAN, not SQLPLUS or ADRCI.
$ rman
Recovery Manager: Release 11.2.0.1.0 - Production on Wed Sep 11 18:45:11 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
RMAN> backup archivelog all delete input;
If you’ve got RMAN-06171: not connected to target database, than try to use rman target / instead of just rman
Wait a long time and your archivelog (that was using up all that space) will be gone. So, you can shutdown/startup your database and be back in business.
сейчас с ораклом дела практически не имею — просто у меня ранее было подобное на тяжелых запросах — коннект к ораклу был через одбс — отваливало по таймауту соединения — лечил установкой в реестре параметра ConnectionTimeout в ноль — не разрывать коннект до окончания выполнения
также — из загашников 
— нытырил пока свою проблемау не разрешил
==================================================
ORA-03113: end-of-file on communication channel
Cause: The connection between Client and Server process was broken. It may also happen if the external agent extproc crashes for some reason.
Action: There was a communication error that requires further investigation. First, check for network problems and review the SQL*Net setup.
Also, look in the alert.log file for any errors. Finally, test to see whether the server process is dead and whether a trace file was generated
at failure time. There may be some system calls in the .NET function which might terminate the process. Remove such calls.
==================================================
На самом деле 3113 часто (не всегда) является следствием каких-либо багов Oracle, так что вопрос может потребовать более детального исследования вплоть до обращения в техподдержку Oracle.
Ну а alert.log в подобных случаях желательно посмотреть в любом случае
Оказывается одним из способов решения этой проблемы является простое удаление статистики. Именно статистики, а не индексов.
В случае, если это не помогло, ее всегда можно восстановить средствами Оракл
==================================================
Обычно связана с аппаратными сбоями, при этом нередко имеет
динамический характер: то есть, то нет. При возникновении нужно
искать соответствующий trace file и анализировать его.
Посмотрите хватает операционке памяти и т. п.
Возможно ваш запрос съел большую часть ресурсов и оракл не поймал их.
Скорей всего это вопрос к админам (пусть ставят патчи).
6.2.34 ORA-03113: End-of-File on Communication Channel
Cause: This error can occur under several circumstances and indicates that the
Oracle server process has failed.
Action: There is one case that may be encountered during an upgrade that has a
known solution. When running on certain 64-bit platforms, the RDBMS bug 2614728
may cause the defnavpg.sql script to fail. If you are on a 64-bit platform, check
your upgrade log file to see if the problem is encountered in the following
context:
#— Beginning inner script: wwd/defnavpg
# Create seeded navigation pages for page groups declare
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
If it is in this context, apply the patch for bug 2614728 for your platform.
Restore from your backup, and run the upgrade again.
==================================================
упс, упустил — еще непосредственно установка ODBCTimeout на сам запрос перед выполнением в 0 — тоже где то в реестре есть, но мне так проще было
Oerr Utility output:
Cause: The connection between Client and Server process was broken.
Action: There was a communication error that requires further investigation.
Check the alert_sid.log file on the server. This may be an indication that the communications link may have gone down at least temporarily, or it may indicate that the server has gone down.
When we are going to start the Oracle database, i am getting the ORA-03113 error during the startup command. My first step is looking into the alert log file which helps us to find cause of error.
In Research found following reasons of error:
Reason 1:
If you working on one SQLPLUS session and from another session DBA shutdown the database then on executing query from your session will give the error as follows:
SQL> select * from dual;
select * from dual
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 10308
Session ID: 9 Serial number: 3
Solution 1:
Reconnect with SQLPLUS and run the command again.
Reason 2:
If you are going to start the database and your Recovery file destination is full then you will also get the following error on db_recovery_file_dest is full.
SQL> startup
ORACLE instance started.
Total System Global Area 23584982528 bytes
Fixed Size 2452778 bytes
Variable Size 4531678966 bytes
Database Buffers 2342356778 bytes
Redo Buffers 25876431 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 2588
Session ID: 1705 Serial number: 5
Solution 2:
1. Checked the alert log find, we find the db_recovery_file_dest is full and alert log is giving following warning:
ORA-19815: WARNING: db_recovery_file_dest_size of 2456687415514 bytes is 100.00% used, and has 0 remaining bytes available.
2. Open the Database in mount state
startup mount
3. Check and increase the parameter current value:
Show parameter db_recovery_file_dest_size
-- add 10GB size more to this parameter
alter system set db_recovery_file_dest_size = 75G scope=both;
4. Open the Database.
alter database open;
5. Fixed the issue with RMAN.
RMAN> backup archivelog all delete input;
Reasons 3:
Redo log file seems inactive or corrupted.
Solution 3:
1. Startup the instance in nomount:
SQL> startup nomount
ORACLE instance started.
Total System Global Area 2147483648 bytes
Fixed Size 2926472 bytes
Variable Size 1224738936 bytes
Database Buffers 905969664 bytes
Redo Buffers 13848576 bytes
2. Open database into mount state:
alter database mount;
Database altered.
3. Clear the redo log files having issue due to power failure or unclean shutdown of database.
SQL> alter database clear unarchived logfile group 1;
Database altered.
SQL> alter database clear unarchived logfile group 2;
Database altered.
SQL> alter database clear unarchived logfile group 3;
Database altered.
4. Shutdown the database and open it.
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 2147483648 bytes
Fixed Size 2926472 bytes
Variable Size 1224738936 bytes
Database Buffers 905969664 bytes
Redo Buffers 13848576 bytes
Database mounted.
Database opened.
Причины выдачи сообщений об ошибках ORA-12571 и ORA-ОЗПЗво многом похожи. Оба сообщения свидетельствуют о преждевременном разрыве соединения. Отчасти это может быть обусловлено большим расстоянием между клиентом и сервером. Одно из возможных решений состоит в увеличении числа попыток повторного соединения для протокола TCP/IP. Для этого нужно внести изменения в реестр Windows на машине клиента.
При операциях с реестром всегда есть риск принести больше вреда,
чем пользы. Следует подходить к этому делу с большой осторожностью. Не забудьте сделать резервную копию перед внесением каких-либо изменений.
Вам предстоит добавить параметр TcpMaxDataRetransmissions (типа REG_DWORD) со значением 15 в реестр Windows NT на машине клиента.
Ниже приводится подробное пошаговое описание этой процедуры.
Откройте меню Start и выберите пункт Run. Откроется диалоговое окно Run.
Введите regedt32 в поле Open и нажмите Enter. Использование regedt32 вместо regedit вызвано тем, что вы добавляете параметр, а не просто просматриваете или удаляете данные реестра.
Убедитесь, что в меню View установлен режим «Tree and Data».
Найдите окно с заголовком «HKEY_LOCAL_MACHTNE on Local Machine» и дважды щелкните на папке SYSTEM. На рис. 14.8 показан редактор реестра с окном HKEY_LOCAL_MACHINE и выбранным разделом
Дважды щелкните на папке CurrentControlSet.
Дважды щелкните на папке Services.
Дважды щелкните на папке Tcpip.
Щелкните на папке Parameters.
Выберите в меню Edit пункт Add Value.
В поле Value Name введите TcpMaxDataRetransmissions.
Выберите REG_DWORD в раскрывающемся списке Data Туре.
Щелкните на кнопке ОК.
В диалоговом окне DWORD Editor введите число 15 в поле Data и убедитесь, что выбран переключатель Hex.
Щелкните на кнопке ОК.
В панели данных должен появиться новый параметр. Если этого произошло, повторите описанные шаги.
Если на машине клиента установлена Windows 95, то для увеличения числа попыток повторной передачи нужно добавить в реестр параметр MaxDataRetries типа REG_DWORD со значением 15. Это делается практически также, как и в Windows NT, однако вместо regedt32 используется regedit. Первые шесть шагов полностью совпадают, а остальные шаги, начиная с седьмого, перечислены ниже.
Дважды щелкните на папке vxd.
Щелкните на папке MSTCP.
В меню Edit выберите New, а затем String Value.
10. В правой панели появится поле со строкой «New Value #1».
Введите вместо нее MaxDataRetries и нажмите Enter.
Щелкните правой кнопкой на новом параметре и выберите в появившемся контекстном меню пункт Modify.
Введите число 15 в поле Value Data.
В панели данных должен появиться новый параметр. Если этого не произошло, повторите описанные шаги.
Другая причина, по которой можно получить сообщение ORA-03113, заключается в том, что Net8 пытается передать пакет пять раз, пока не зафиксирует отказ сети. Значение 5 — это число попыток передачи пакета, устанавливаемое по умолчанию для протокола TCP/IP в Windows 95 и Windows NT. С другой стороны, сервер может не получить последний переданный пакет. В этом случае возвращается ошибка с номером 54, интерпретируемая как «connection reset/network is busy» («сброс соединения/занятость сети»). Получив такую ошибку, Net8 предполагает, что сервер отключился, и закрывает соединение. Необходимо проверить, что произошло на самом деле — отказ сети (возможно, временный) или отключение сервера.
Если вам потребуется дополнительная информация по диагностике этой ошибки, обратитесь к документации на операционную систему.
ORA-03121: no interface driver connection-function not performed
Вы получите это сообщение, если по ошибке укажете в строке соединения Net8 префикс в стиле SQL*Net версии I. Очевидное решение — не использовать перечисленные ниже префиксы:
Т:
X:
Р:
Другая возможная причина состоит в том, что на клиентской машине, не имеющей локальной базы данных, в строке соединения были указаны только имя пользователя и пароль. Решение столь же очевидно — убедитесь, что вводится полная строка соединения.
| < Предыдущая | Следующая > |
|---|