1. Причины
Вход в учетную запись пользователя через PL / SQL запрашивает эту информацию, что приводит к невозможности обычного входа в систему. Данные запроса показывают, что произошла ошибка ORA-00257. Архивный журнал заполнен и занимает все оставшееся место на жестком диске. Это можно решить, просто удалив журнал, чтобы освободить место для хранения. ,
2. Решение
2.1 Пользователь root входит на сервер, затем переключает пользователя Oracle и подключается к оракулу с пользователем DBA
[[email protected] ~]# su - oracle
[[email protected] ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Производство во вторник 29 октября 11:32:35 2019
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Подключен к:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>
2.2 Проверьте использование области флэш-восстановления
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;
Результаты:
Интерфейс выглядит немного неудобно, проверьте текущий размер строки, по умолчанию установлено значение 80, можно установить значение 200 или более и выполнять SQL после настройки
SQL> show linesize;
linesize 80
SQL> set linesize 200;
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;
Вы можете видеть, что архив уже очень большой, достигнув 99,82.
2.3 Рассчитать пространство, уже занятое областью мгновенного восстановления
SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;
SUM(PERCENT_SPACE_USED)*3/100
-----------------------------
2.9946
2.4 Найти каталог восстановления, показать параметр recovery
SQL> show parameter recover;
NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
db_recovery_file_dest string /oracle/flash_recovery_area
db_recovery_file_dest_size big integer 10G
recovery_parallelism integer
Результаты показывают, что архивный журнал находится в каталоге / oracle / flash_recovery_area. Введите этот каталог и введите соответствующую папку архивного журнала в соответствии с идентификатором экземпляра базы данных. Удалите некоторые файлы из неиспользованного каталога дат. Примечание. Рекомендуется создать резервную копию перед удалением.
[[email protected] ~]# cd /oracle/flash_recovery_area
[[email protected] flash_recovery_area]# ll
total 8
drwxr-x---. 2 oracle oinstall 4096 Feb 9 2018 mzrswdb
drwxr-x--- 3 oracle oinstall 4096 Feb 9 2018 MZRSWDB
[[email protected] flash_recovery_area]# cd MZRSWDB/archivelog
[[email protected] archivelog]# pwd
/oracle/flash_recovery_area/MZRSWDB/archivelog
【нота】 После удаления архивного журнала вы должны использовать RMAN для поддержки управляющего файла, иначе отображение пространства не будет освобождено.
2.5 Переключитесь на пользователя Oracle после входа на сервер в другом окне и введите обслуживание RMAN
[[email protected] ~]# su - oracle
[[email protected] ~]$ rman target sys/pass
Менеджер восстановления: выпуск 11.2.0.1.0 - Производство во вторник 29 октября 14:24:46 2019
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Подключиться к целевой базе данных: MZRSWDB (DBID=1046999851)
RMAN>
2.6. Проверьте бесполезный архив
RMAN> crosscheck archivelog all;
Результаты
2.7 Удалить просроченные архивы
RMAN> delete expired archivelog all;
Канал выпущен: ORA_DISK_1
Назначенный канал: ORA_DISK_1
Канал ORA_DISK_1: SID = 195 тип устройства = DISK
Описание не соответствует ни одному архивному журналу в базе данных.
** 【Примечание】 ** Приведенный выше результат выполнения показывает, что нет совпадений с просроченным архивом.
2.8 Удалить все архивные журналы 7 дней назад
RMAN> delete archivelog until time 'sysdate-7' ;
Последовательность ключевых слов S нижний предел времени
------- ---- ------- - ------------------
1397 1 1490 A 2019-10-2006:29:12
Имя: /oracle/flash_recovery_area/MZRSWDB/archivelog/2019_10_21/o1_mf_1_1490_gtt8llw4_.arc
, , , Сохранить большую часть контента. , ,
1398 1 1491 A 2019-10-2111:13:22
Имя: /oracle/flash_recovery_area/MZRSWDB/archivelog/2019_10_22/o1_mf_1_1491_gtx6f5mw_.arc
Вы уверены, что хотите удалить вышеуказанный объект? (Введите ДА или НЕТ)?
Имя файла архивного журнала =/oracle/flash_recovery_area/MZRSWDB/archivelog/2019_10_17/o1_mf_1_1487_gtjxc3b4_.arc RECID=1394 STAMP=1021932387
Удаленный архив журнала
, , , Сохранить большую часть контента. , ,
Удаленный архив журнала
Имя файла архивного журнала =/oracle/flash_recovery_area/MZRSWDB/archivelog/2019_10_22/o1_mf_1_1491_gtx6f5mw_.arc RECID=1398 STAMP=1022334885
391 объект удален
** 【Примечание】 ** Вы уверены, что хотите удалить вышеуказанные объекты (введите ДА или НЕТ)?Введите YES и нажмите Enter Подсказка 391 объект был удален
2.9. Опросите снова и обнаружите, что коэффициент использования нормальный, который упал до 1,45
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------------------------------------------------------ ------------------ ------------------------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 1.45 0 6
BACKUP PIECE 0 0 0
IMAGE COPY 0 0 0
FLASHBACK LOG 0 0 0
FOREIGN ARCHIVED LOG 0 0 0
7 строк были выбраны.
2.10. Пересчитайте пространство, уже занятое областью флеш-восстановления.
SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;
SUM(PERCENT_SPACE_USED)*3/100
-----------------------------
.0435
2.11 Войдите в систему пользователя целевой базы данных.
SQL> conn sdrs_zpxx/sdrszpxx_jyt
связаны.
Пока проблема решена.
2.12 Переключить окно для выхода из системы входа пользователя в базу данных и регистрации обслуживания RMAN
Выход из Oracle
SQL> exit
Из базы данных Oracle 11g Enterprise Edition, выпуск 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Опции тестирования майнинга и реального приложения отключены
[[email protected] ~]$ exit
logout
Выйти из обслуживания входа RMAN
RMAN> exit
Менеджер восстановления завершен.
[[email protected] ~]$ exit
logout
3 Резюме
Так называемый архив журнала — это архивирование и сохранение оперативного журнала в виде фиксированного файла на жестком диске, что удобно для последующего восстановления и запроса. Конечно, обязательным условием является то, что база данных находится в режиме архива.
После того, как база данных Oracle заархивирована, из-за слишком большого количества журналов и полного пространства файл повторного выполнения базы данных не может быть заархивирован, и существует проблема, связанная с зависанием базы данных oracle и недоступностью базы данных, эта проблема появляется ,
В производственной среде вы можете сформулировать соответствующую стратегию хранения архивных журналов в соответствии с вашими потребностями. Во многих случаях после использования полного резервного копирования rman архив будет сохранен. Вы можете добавить журнал удаления архивов после сценария полного резервного копирования. Команда, потому что после полного резервного копирования, архив также будет сохранен в соответствующий резервный фрагмент, который может быть восстановлен путем резервного копирования.
Hello Readers, You are here because you faced ORA-00257: Archiver error. Connect AS SYSDBA only until resolved error ? Lets come to point ->
ORA-00257: Archiver error. Connect AS SYSDBA only until resolved error means archiver process is stuck because of various reasons due to which redo logs are not available for further transaction as database is in archive log mode and all redo logs requires archiving. And your database is in temporary still state.
Environment Details –
OS Version – Linux 7.8
DB Version – 19.8 (19)
Type – Test environment
SQL> select name,open_mode,database_role,log_mode from v$database;
NAME OPEN_MODE DATABASE_ROLE LOG_MODE
-------------------- -------------------- ---------------- ----------
ORACLEDB READ WRITE PRIMARY ARCHIVELOG
SQL>
SQL> select GROUP#,SEQUENCE#,BYTES,MEMBERS,ARCHIVE,STATUS from v$log;
GROUP# SEQUENCE# BYTES MEMBERS ARC STATUS
------ --------- --------- ------- --- --------
1 25 209715200 2 NO CURRENT
2 23 209715200 2 NO INACTIVE
3 24 209715200 2 NO INACTIVE
SQL> There are various reason which cause this error-
- One of the common issue here is archive destination of your database is 100% full.
- The mount point/disk group assigned to archive destination or FRA is dismounted due to OS issue/Storage issue.
- If db_recovery_file_dest_size is set to small value.
- Human Error – Sometimes location doesn’t have permission or we set to location which doesn’t exists.
What Happens when ORA-00257: Archiver error. Connect AS SYSDBA only until resolved Error occurs
Lets us understand what end user see and understand there pain as well. So when a normal user try to connect to the database which is already in archiver error (ORA-00257: Archiver error. Connect AS SYSDBA only until resolved ) state then they directory receive the error –
ORA-00257: Archiver error. Connect AS SYSDBA only until resolved on the screen.
SQL> conn dbsnmp/oracledbworld
ERROR:
ORA-00257: Archiver error. Connect AS SYSDBA only until resolved.
Warning: You are no longer connected to ORACLE.
SQL>
You might be wondering what happens to the user which is already connected to the oracle database. In this case if they trying to do a DML, it will stuck and will not come out. For example here I am just trying to insert 30k record here again which is stuck and didn’t came out.
SQL> conn system/oracledbworld
connected.
SQL> create table oracledbworld2 as select * from oracledbworld;
Table created.
SQL> insert into oracledbworld select * from oracledbworld2;
29965 rows created.
SQL> /
How to Check archive log location
Either you can fire archive log list or check your log_archive_dest_n to see what location is assigned
SQL> select name,open_mode,database_role,log_mode,force_logging from v$database;
NAME OPEN_MODE DATABASE_ROLE LOG_MODE FORCE_LOGGING
--------- ------------ ---------------- ------------ ----------------
ORACLEDB READ WRITE PRIMARY ARCHIVELOG YES
SQL>
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 18
Next log sequence to archive 20
Current log sequence 20
SQL> When you see USE_DB_RECOVERY_FILE_DEST, that means you have enabled FRA location for your archive destination. So here you have to check for db_recover_file_dest to get the diskgroup name / location where Oracle is dumping the archive log files.
SQL> show parameter db_recover_file_destWhat are Different Ways to Understand if there is ORA-00257: Archiver error. Connect AS SYSDBA only until resolved Error
There are different ways to understand what is there issue. Usually end user doesn’t understand the ORA- code and they will rush to you with a Problem statement as -> DB is running slow or I am not able to login to the database.
Check the Alert Log First –
Always check alert log of the database to understand what is the problem here –
I have set the log_archive_dest_1 to a location which doesn’t exists to reproduce ORA-00257: Archiver error. Connect AS SYSDBA only until resolved Error. So alert log clearly suggest that
ORA-19504: failed to create file %s
ORA-27040: file create error, unable to create file
Linux-x86-64 Error: 13: Permission denied.
In middle of the alert – “ORACLE Instance oracledb, archival error, archiver continuing”
At 4th Last line you might seen the error – “All online logs need archiving”
Check Space availability –
Once you rule out that there is no human error, and the archive log location exists Now you should check if mount point/ disk group has enough free space available, if it is available for writing and you can access it.
If your database is on ASM, then you can use following query – Check for free_mb/usable file mb and state column against your diskgroup name.
SQL> select name,state,free_mb,usable_file_mb,total_mb from v$asm_diskgroup;If your database is on filesystem, then you can use following OS command –
For linux, sun solaris -
$df -kh
For AIX -
$df -gt If case you have FRA been used for archive destination then we have additional query to identify space available and how much is allocated to it.
SQL> select name, space_limit as Total_size ,space_used as Used,SPACE_RECLAIMABLE as reclaimable ,NUMBER_OF_FILES as "number" from V$RECOVERY_FILE_DEST;
NAME TOTAL_SIZE USED RECLAIMABLE number
---------------------------------- ---------- ---------- ----------- ----------
/u01/app/oracle/fast_recovery_area 10485760 872185344 68794880 25SQL> Select file_type, percent_space_used as used,percent_space_reclaimable as reclaimable,number_of_files as "number" from v$recovery_area_usage;
FILE_TYPE USED RECLAIMABLE number
----------------------- ---------- ----------- ----------
CONTROL FILE 100.94 0 1
REDO LOG 6000 0 3
ARCHIVED LOG 1900.78 452.02 18
BACKUP PIECE 306.09 204.06 3
IMAGE COPY 0 0 0
FLASHBACK LOG 0 0 0
FOREIGN ARCHIVED LOG 0 0 0
AUXILIARY DATAFILE COPY 0 0 0
8 rows selected.
You can look at sessions and event to understand what is happening in the database.
If you see there are 3 sessions, SID 237 is my session Rest two sessions are application session and when we look at the event of those two application session it clearly suggest session is waiting for log file switch (archiving needed).
select sid,serial#,event,sql_id from v$session where username is not null and status='ACTIVE';
SID SERIAL# EVENT SQL_ID
--- ---------- ---------------------------------------- -------------
237 59305 SQL*Net message from client 7wcvjx08mf9r6
271 46870 log file switch (archiving needed) 7zq6pjtwy552p
276 18737 log file switch (archiving needed) a5fasv0jz2mx2
How to Resolve ORA-00257: Archiver error. Connect AS SYSDBA only until resolved error
It’s always better to know the environment before firing any command. Archive deletion can be destructive for DR setup or Goldengate Setup.
Solution 1
Check if you have DR database and it’s in sync based on that take a call of clearing the archive until sequence. You can use following command on RMAN prompt.
delete archivelog until sequence <sequence> thread <thread no>;Solution 2
You can change destination to a location which has enough space.
SQL>archive log list
SQL>show parameter log_archive_dest_1
(or whichever you are using it, usually we use dest_1)
Say your diskgroup +ARCH is full and +DATA has lot of space then you can fire
SQL> alter system set log_archive_dest_1='location=+DATA reopen';You might be wondering why reopen. So since your archive location was full. There are chances if you clear the space on OS level and archiver process still remain stuck. Hence we gave reopen option here.
Solution 3
Other reason could be your db_recovery_file_dest_size is set to lower size. Sometimes we have FRA enabled for archivelog. And we have enough space available on the diskgroup/ filesystem level.
archive log list;
show parameter db_recovery_file_dest_size
alter system set db_recovery_file_dest_size=<greater size then current value please make note of filesystem/diskgroup freespace as well>
example -
Initially it was 20G
alter system set db_recovery_file_dest_size=100G sid='*';
Reference – archive Document 2014425.1
Содержание
- 1 1. Закончилось место на дисковом томе, куда пишутся архивные логи
- 1.1 Варианты минимизации ошибок:
- 2 2. Закончилось место выделенное под FRA
ORA-00257: archiver error. Connect internal only, until freed. (Ошибка архиватора. Не могу подсоедениться пока занят ресурс)
Эта ошибка может быть вызвана несколькими причинами:
1. Закончилось место на дисковом томе, куда пишутся архивные логи
Для начала нужно понять, куда пишутся архивлоги. Для этого возьмем значения следующих параметров в представлении V$PARAMETER:
- LOG_ARCHIVE_DEST (Устаревший, используется для БД редакции не Enterprise)
- LOG_ARCHIVE_DEST_n
- DB_RECOVERY_FILE_DEST. Этот параметр используется, если не установлено значение для любого параметра LOG_ARCHIVE_DEST_n, либо если для параметра LOG_ARCHIVE_DEST_1 установлено значение USE_DB_RECOVERY_FILE_DEST.
SELECT NAME, VALUE
FROM V$PARAMETER
WHERE ( NAME LIKE 'db_recovery_file_dest'
OR NAME LIKE 'log_archive_dest__'
OR NAME LIKE 'log_archive_dest___'
OR NAME = 'log_archive_dest'
OR NAME = 'log_archive_duplex_dest')
AND VALUE IS NOT NULL;
И проверим, по каким из путей нет дискового пространства. Для этого можно воспользоваться командой df -Pk. Далее либо чистим место, на тех томах, где пространство занято на 100 процентов, либо командой ALTER изменяем том на который пишутся архивлоги.
Варианты минимизации ошибок:
1. Если используется параметр LOG_ARCHIVE_DEST, то можно указать дополнительно параметры LOG_ARCHIVE_DUPLEX_DEST и LOG_ARCHIVE_MIN_SUCCEED_DEST.
- LOG_ARCHIVE_DUPLEX_DEST — в этом параметре указываем каталог на дисковом томе, отличном от используемого в параметре LOG_ARCHIVE_DEST.
- LOG_ARCHIVE_MIN_SUCCEED_DEST — значение этого параметра указываем равным 1. В этом случае, если том указанный в LOG_ARCHIVE_DEST будет заполнен на 100 процентов, но при этом архивлог будет записан в каталог указанный в LOG_ARCHIVE_DUPLEX_DEST, мы не получим ошибку.
ALTER SYSTEM SET LOG_ARCHIVE_DEST = '/u01/ARC/TST/' SCOPE=spfile; ALTER SYSTEM SET LOG_ARCHIVE_DUPLEX_DEST = '/u02/ARC/TST/' SCOPE=spfile; ALTER SYSTEM SET LOG_ARCHIVE_MIN_SUCCEED_DEST = 1 SCOPE=spfile;
И перезапускаем БД.
2. Если используются параметры LOG_ARCHIVE_DEST_n. В данном случае нам может помочь опция ALTERNATE этого параметра. В случае, если недоступен путь для архивирования лог файла, то архивирование идет по альтернативно указанному пути:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=/u01/ARC/TST/ MANDATORY MAX_FAILURE=1 REOPEN ALTERNATE=LOG_ARCHIVE_DEST_2' SCOPE=both; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE SCOPE=both; ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='LOCATION=/u02/ARC/TST/ MANDATORY' SCOPE=both; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ALTERNATE SCOPE=both; ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=standby_path1 ALTERNATE=LOG_ARCHIVE_DEST_4' SCOPE=both; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3=ENABLE SCOPE=both; ALTER SYSTEM SET LOG_ARCHIVE_DEST_4='SERVICE=standby_path2' SCOPE=both; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=ALTERNATE SCOPE=both;
3. Если используется параметр DB_RECOVERY_FILE_DEST, желательно перейти на использование LOG_ARCHIVE_DEST_n.
Для просмотра текущих путей копирования архивлогов можно воспользоваться следующим представлением: V$ARCHIVE_DEST.
2. Закончилось место выделенное под FRA
Если архивлоги настроены на запись в DB_RECOVERY_FILE_DEST_SIZE, то можно так же словить сообщение ORA-00257, в alert.log при этом будет сообщение с ошибкой ORA-19815:
ARC0: Error 19809 Creating archive log file to '/u01/FRA/TST/archivelog/2013_06_28/o1_mf_1_5734_%u_.arc' Errors in file /orasft/app/diag/rdbms/dwh/TST/trace/TST_arc0_8386.trc: ORA-19815: WARNING: db_recovery_file_dest_size of 644245094400 bytes is 100.00% used, and has 0 remaining bytes available. ************************************************************************ You have following choices to free up space from recovery area: 1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard, then consider changing RMAN ARCHIVELOG DELETION POLICY. 2. Back up files to tertiary device such as tape using RMAN BACKUP RECOVERY AREA command. 3. Add disk space and increase db_recovery_file_dest_size parameter to reflect the new space. 4. Delete unnecessary files using RMAN DELETE command. If an operating system command was used to delete files, then use RMAN CROSSCHECK and DELETE EXPIRED commands. ************************************************************************
Тут же дают и варианты решения:
- Изменить политику удержания и удаления архивлогов rman.
- Сделать бекап архивлогов на ленту с удалением с диска.
- Добавить дисковое пространство во FRA командой: ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 1024g SCOPE=both;
- Удалить ненужные архивлоги командами RMAN:
orasft@DB:/home/orasft$ rman target / -- Если архивлоги не нужны для бекапа: DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'; -- Если архивлоги нужны для бекапа: CROSSCHECK ARCHIVELOG ALL; DELETE EXPIRED ARCHIVELOG ALL;
При удалении архивлогов можем получить ошибку:
RMAN-06207: WARNING: 1235 objects could not be deleted for DISK channel(s) due RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status RMAN-06210: List of Mismatched objects RMAN-06211: ========================== RMAN-06212: Object Type Filename/Handle RMAN-06213: --------------- --------------------------------------------------- RMAN-06214: Archivelog /u01/FRA/archivelog/2013_06_09/o1_mf_1_6468_95bhbb33_.arc RMAN-06214: Archivelog /u01/FRA/archivelog/2013_06_09/o1_mf_1_6469_95bhh7rb_.arc
Это означает, что rman не может найти файлы для удаления. Тут же нам предлагают воспользоваться командой CROSSCHECK перед удалением: CROSSCHECK ARCHIVELOG ALL;
Чтобы избежать возникновения ошибки переполнения места выделенного под FRA используем для архивлогов параметр LOG_ARCHIVE_DEST_n.
Проверить насколько заполнена FRA можно следующей командой:
SELECT SUM (PERCENT_SPACE_USED) AS "% Used FRA" FROM V$FLASH_RECOVERY_AREA_USAGE S;
Автор Андрей Котован
When I try connecting to my database, I get the following error.
ORA-00257:archiver error. Connect internal only until freed.
Till yesterday, the database was pretty functional.
Any workaround?
skaffman
398k96 gold badges816 silver badges768 bronze badges
asked Apr 26, 2011 at 4:27
3
In SQL*Plus, can you
SQL> show parameter log_archive
- If
LOG_ARCHIVE_STARTis FALSE,
you’ll want to set it to TRUE. - If
LOG_ARCHIVE_DESTpoints to an
invalid directory, you’ll want to
change it to point to a valid
directory.
answered Apr 26, 2011 at 6:39
Justin CaveJustin Cave
226k24 gold badges364 silver badges382 bronze badges
3
ORA-00257:archiver error is occured when your archivelog reached the FRA limit. So you have to clear the archivelogs or you may increase the FRA limit.
To clear the archivelogs, connect to the command prompt and follow steps below:
rman target /
RMAN> delete archivelog all;
It will ask for confirmation and you have to give ‘yes’.
answered Jun 19, 2018 at 11:54
1
please note that you can only access SQL*PLUS if you login as
sqlplus / as sysdba
Plus, I think the problem here is space quota for archiving
reaching its max limit.
So its best to clear the logs after making backup on a flash or something
answered Dec 7, 2011 at 6:10
ORA-00257: archiver error. Connect internal only, until freed. problem can be solved as following:
copy archivelog folder to a new destination and empty this directory.
The real problem is that online-backup limit increased what was set as n GB and that become full when you empty this archivelog folder then it will start working fine
answered Apr 6, 2017 at 10:29
GhayelGhayel
1,1132 gold badges10 silver badges19 bronze badges
I have encountered this error couple of times, it simply tells that archivelog space has exhausted and need to be freed.
run cmd as administrator
> set oracled_sid=write_oracle_sid_here
> rman target sys/put_sys_password_here
> crosscheck archivelog all;
> delete noprompt expired archivelog all;
>exit;
answered Aug 13, 2019 at 6:01
Sadeq AramidehSadeq Aramideh
431 gold badge2 silver badges7 bronze badges
Open rman or cmd, then type:
connect target sys/live; press enter
then:
delete archivelog all; press enter
Ask for confirmation press y then enter.
Your issue will be solved.
answered Aug 17, 2021 at 8:48
I am getting below error while connecting to oracle database.
java.sql.SQLException: ORA-00257: Archiver error. Connect AS SYSDBA only until resolved.07-09-2016 12:25:44 ERROR DBUtils:122 - loginUser Exception :java.sql.SQLException: ORA-00257: Archiver error. Connect AS SYSDBA only until resolved.
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:447)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:389)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:382)
at oracle.jdbc.driver.T4CTTIoauthenticate.processError(T4CTTIoauthenticate.java:444)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:513)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:227)
at oracle.jdbc.driver.T4CTTIoauthenticate.doOSESSKEY(T4CTTIoauthenticate.java:407)
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:416)
at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:553)
at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:254)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:528)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at com.sne.dao.DBUtils.loginUser(DBUtils.java:55)
at com.sne.servlets.SELogin.doPost(SELogin.java:46)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:395)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:306)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:323)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1719)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Error While Connecting db through SQL Developer…
asked Sep 7, 2016 at 6:59
Developer DeskDeveloper Desk
2,2948 gold badges36 silver badges76 bronze badges
The archiver is responsible for taking the online redo logs and writing them off to a safe place in the event they are needed for a database recovery.
Currently they are unable to do this, so they are preventing any operation on the database until the DBA goes in to sort it all out.
answered Sep 7, 2016 at 7:04
Gary MyersGary Myers
34.9k3 gold badges49 silver badges74 bronze badges
0
Since the Oracle archive is full. Create a maintenance job to perform a daily cleanup.
answered May 5 at 7:09
Ajay TakurAjay Takur
6,0325 gold badges38 silver badges54 bronze badges