Error oracle ora 00257 archiver error

ORA-00257: Archiver error. Connect AS SYSDBA only until resolved solution- delete archivelog until sequence thread ; or alter system set lo

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-

  1. One of the common issue here is archive destination of your database is 100% full.
  2. The mount point/disk group assigned to archive destination or FRA is dismounted due to OS issue/Storage issue.
  3. If db_recovery_file_dest_size is set to small value.
  4. 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_dest

What 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”

ORA-00257: Archiver error. Connect AS SYSDBA only until resolved Error

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	  25
SQL> 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. Ошибка ORA-00257: archiver error. Connect internal only, until freed
  2. 1. Закончилось место на дисковом томе, куда пишутся архивные логи
  3. Варианты минимизации ошибок:
  4. 2. Закончилось место выделенное под FRA
  5. Oracle: Resolve ORA-00257 – Connect AS SYSDBA only until resolved
  6. Check #1: Are we physically out of space?
  7. Check #2: The Alert Log
  8. Check #3: Check the space allocated to DB_RECOVERY_FILE_DEST_SIZE
  9. SQL*Plus
  10. Check #4: Are backups succeeding?
  11. Solutions:
  12. Alternate solutions
  13. OPSS: java.sql.SQLException: ORA-00257: Archiver error. Connect AS SYSDBA only until resolved. (Doc ID 2589094.1)
  14. Applies to:
  15. Symptoms
  16. Cause
  17. To view full details, sign in with your My Oracle Support account.
  18. Don’t have a My Oracle Support account? Click to get started!

Ошибка ORA-00257: archiver error. Connect internal only, until freed

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.

И проверим, по каким из путей нет дискового пространства. Для этого можно воспользоваться командой 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, мы не получим ошибку.

И перезапускаем БД.

2. Если используются параметры LOG_ARCHIVE_DEST_n. В данном случае нам может помочь опция ALTERNATE этого параметра. В случае, если недоступен путь для архивирования лог файла, то архивирование идет по альтернативно указанному пути:

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:

Тут же дают и варианты решения:

  1. Изменить политику удержания и удаления архивлогов rman.
  2. Сделать бекап архивлогов на ленту с удалением с диска.
  3. Добавить дисковое пространство во FRA командой: ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 1024g SCOPE=both;
  4. Удалить ненужные архивлоги командами RMAN:

При удалении архивлогов можем получить ошибку:

Это означает, что rman не может найти файлы для удаления. Тут же нам предлагают воспользоваться командой CROSSCHECK перед удалением: CROSSCHECK ARCHIVELOG ALL;

Чтобы избежать возникновения ошибки переполнения места выделенного под FRA используем для архивлогов параметр LOG_ARCHIVE_DEST_n.

Проверить насколько заполнена FRA можно следующей командой:

Источник

Oracle: Resolve ORA-00257 – Connect AS SYSDBA only until resolved

Recently, one of the Oracle users complained that the database was unusable and received the error below

Check #1: Are we physically out of space?

When the host is out of space on the drive/device where the FRA has been set, it can produce this error. We run Oracle on Windows. So, it could be

  • Shadow Copy
  • Orphaned files not referenced by the database
  • Extraneous non-database files
  • Archivelog files no longer needed after being backed up (DELETE INPUT option)

I looked at the space situation and it looked good (PowerShell command is from the dbatools module and allows you to get this server space info. from your own host)

Check #2: The Alert Log

Next, I looked at the alert log and saw the problem and the solution was offered right there:

Sorry, the messages are in French. I did a Google Translate to English below

Check #3: Check the space allocated to DB_RECOVERY_FILE_DEST_SIZE

Basically it is saying that the “BACKUP RECOVERY AREA” is full. Although there is ample diskspace, the parameter DB_RECOVERY_FILE_DEST_SIZE determines how much space Oracle can use for database recovery related activities.

To check the space allocated to DB_RECOVERY_FILE_DEST_SIZE you could use one of the following options

SQL*Plus

SHOW PARAMETER DB_RECOVERY_FILE_DEST_SIZE

This also shows you the current usage as opposed to just the setting with SQL*Plus above

As can be seen, I have it set to 250GB and most of it is used:

NAME Size MB Used MB
\MyHostNameOrafra$ 256000 255991

Check #4: Are backups succeeding?

Check your backup history to make sure Archived Redo Log File backups are successful. If the backups are failing then the Oracle Flash Recovery Area (FRA) may get full. Run archive log backups using the standard procedure you use in your shop. To check if backups are failing you can use this SQL (I am not the author, original source unknown)

Run in SQL*Plus. Substitute &NUMBER_OF_DAYS and tweak WHERE clause as necessary

Solutions:

If disk cleanup is necessary, do so. If backups are failing, remedy the situation and get a successful archive log backup. If FRA is too small, increase the size.

In my case today, the solution to the problem is offered in the alert log itself:

I chose to increase the space for DB_RECOVERY_FILE_DEST_SIZE as we are going through other problems with Backup.

Alternate solutions

You could move the archive log files to a different drive/folder where there is space and recatalog them using the command below by pointing to the directory the archive logs were moved to and then crosscheck/delete expired (shown later).

If you know that certain archive log files were already backed up, you could remove them to make room as shown in this post:

Run this in RMAN (and change to disk if you are not using sbt_tape)

Alternatively, you could first backup the archive log files if you can and then remove them from the recovery area. If you are unable to backup for whatever reason, the archive log files can be physically moved to another location for safekeeping (and recatalog later when you move back) and update the RMAN catalog. You need to check the location pointed to by “db_recovery_file_dest”

..physically move the archive log files and update RMAN catalog to reflect the freed-up space in the recovery area.

Источник

OPSS: java.sql.SQLException: ORA-00257: Archiver error. Connect AS SYSDBA only until resolved. (Doc ID 2589094.1)

Last updated on AUGUST 11, 2021

Applies to:

Symptoms

On : 12.2.1.2.0 version, Java Platform Security

When attempting to start servers the following error occurs.

ERROR
————————
05, 2019 6:59:56 PM oracle.security.jps.internal.policystore.util.JpsDataManagerUtil getDBConnection
WARNING: Can not connect DB with URL jdbc:oracle:thin:@// : /
java.sql.SQLException: ORA-00257: Archiver error. Connect AS SYSDBA only until resolved.

at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:466)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:391)
at oracle.jdbc.driver.T4CTTIoauthenticate.processError(T4CTTIoauthenticate.java:503)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:546)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:269)
at oracle.jdbc.driver.T4CTTIoauthenticate.doOSESSKEY(T4CTTIoauthenticate.java:464)
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:637)
at oracle.jdbc.driver.PhysicalConnection.connect(PhysicalConnection.java:793)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:614)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at oracle.security.jps.internal.policystore.util.JpsDataManagerUtil.getDBConnection(JpsDataManagerUtil.java:401)
at oracle.security.jps.internal.policystore.util.JpsDataManagerUtil.isNewSchema(JpsDataManagerUtil.java:249)
at oracle.security.jps.internal.core.datamanager.DataManagerFactoryImpl.isNewSchema(DataManagerFactoryImpl.java:252)
at oracle.security.jps.internal.core.datamanager.DataManagerFactoryImpl.getDBDataManager(DataManagerFactoryImpl.java:319)
at oracle.security.jps.internal.core.datamanager.DataManagerFactoryImpl.getDataManager(DataManagerFactoryImpl.java:161)
at oracle.security.jps.internal.credstore.rdbms.CsfDbmsManager.getDataManager(CsfDbmsManager.java:95)
at oracle.security.jps.internal.credstore.ldap.CsfStoreManager.existsStore(CsfStoreManager.java:298)
at oracle.security.jps.internal.credstore.ldap.CsfStoreManager.completeInit(CsfStoreManager.java:177)
at oracle.security.jps.internal.credstore.rdbms.CsfDbmsManager. (CsfDbmsManager.java:91)
at oracle.security.jps.internal.credstore.rdbms.CsfDbmsManager.createInstance(CsfDbmsManager.java:72)
at oracle.security.jps.internal.credstore.ldap.CsfStoreManager.getInstance(CsfStoreManager.java:121)
at oracle.security.jps.internal.credstore.ldap.LdapCredentialStore.init(LdapCredentialStore.java:188)
at oracle.security.jps.internal.credstore.ldap.LdapCredentialStore.start(LdapCredentialStore.java:1029)
at oracle.security.opss.internal.runtime.ServiceContextImpl.start(ServiceContextImpl.java:220)
at oracle.security.opss.internal.runtime.ServiceContextManagerImpl.createDefaultContext(ServiceContextManagerImpl.java:325)
at oracle.security.opss.internal.runtime.ServiceContextManagerImpl.initialize(ServiceContextManagerImpl.java:242)
at oracle.security.jps.internal.config.OpssCommonStartup$1.run(OpssCommonStartup.java:166)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.security.jps.internal.config.OpssCommonStartup.start(OpssCommonStartup.java:159)
at oracle.security.jps.wls.JpsWlsStartup.start(JpsWlsStartup.java:105)
at oracle.security.jps.JpsStartup.startWithRetry(JpsStartup.java:287)
at oracle.security.jps.JpsStartup.start(JpsStartup.java:252)
at oracle.security.jps.wls.JpsDefaultService.start(JpsDefaultService.java:103)
at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:76)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1262)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:332)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:374)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1213)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1144)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:666)
at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)

Aug 05, 2019 6:59:56 PM oracle.security.jps.internal.credstore.ldap.LdapCredentialStore init
WARNING: Could not create credential store instance. Reason oracle.security.jps.service.policystore.PolicyStoreException: Can not connect DB with URL [jdbc:oracle:thin:@// : / ]
Aug 05, 2019 6:59:56 PM oracle.security.jps.internal.config.OpssCommonStartup start
INFO: Jps startup failed.
: / ]
at oracle.security.jps.internal.config.OpssCommonStartup.start(OpssCommonStartup.java:228)
at oracle.security.jps.wls.JpsWlsStartup.start(JpsWlsStartup.java:105)
at oracle.security.jps.JpsStartup.startWithRetry(JpsStartup.java:287)
at oracle.security.jps.JpsStartup.start(JpsStartup.java:252)
at oracle.security.jps.wls.JpsDefaultService.start(JpsDefaultService.java:103)
at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:76)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1262)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:332)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:374)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1213)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1144)

Cause

To view full details, sign in with your My Oracle Support account.

Don’t have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

Oracle offers a comprehensive and fully integrated stack of cloud applications and platform services. For more information about Oracle (NYSE:ORCL), visit oracle.com. пїЅ Oracle | Contact and Chat | Support | Communities | Connect with us | | | | Legal Notices | Terms of Use

Источник

Источник

A scheduler job which is refreshing materialized views threw an error ORA-00257 in the alert log like this:

ORA-12012: error on auto execute of job 78450
ORA-00257: archiver error. Connect internal only, until freed.
...

Rationale on ORA-00257

The first action we should take is to check all the archived log destinations LOG_ARCHIVE_DEST_n or DB_RECOVERY_FILE_DEST to make sure they have enough space. If they are in good conditions, the possible causes could be from the remote database that is connected by local database links for refreshing local materialized views. Either local or remote database could cause the error, you should release some space to make the database move.

Solutions to ORA-00257

1. Remove ALL Archived Logs in RMAN

If you’re in an urgent situation, you can delete all archived logs without asking anything.

$ rman target /
...
RMAN> delete noprompt archivelog all;

This RMAN command will delete all archived logs without prompting you the confirmation. That is to say, we keep none of online archived logs.

2. Remove Some Archived Logs in RMAN

The following command will keep archived logs only latest 3 days.

RMAN> delete archivelog until time 'sysdate - 3';

The following command will keep archived logs only 1 hour.

RMAN> delete archivelog until time 'sysdate - 1/24';

The following command will keep archived logs only 5 minutes.

RMAN> delete archivelog until time 'sysdate - 5/1440';

3. Remove Some Archived Logs at OS-level

Sometimes, you might be not able to access RMAN in the first place, to free up the space of archived log destinations manually, you can refer to following steps in order to solve ORA-00257.

Find Candidates

List and make sure all the target files are available to move or delete.

For example, we’d like to keep the files newer than 7 days. The following Unix command find will list 7 and 7+ days old files.

$ cd /path/to/archived_log_destination
$ find . -mtime +6 -exec ls -l {} ;

Please make sure the listed file are allowed to be moved or deleted. Furthermore, you should make sure the standby databases have received or applied the archived logs.

Remove Files

Remove all the target files.

$ find . -mtime +6 -exec rm {} ;

So far, the database is not aware of the resulting free space that you just did on OS-level. So we need to notify the database.

Connect RMAN

Connect to the backup database.

$ rman target / catalog sys/password@backupdb

Find Expired Archive Logs

Notify RMAN to check the current status of all archived log files.

RMAN> crosscheck archivelog all;

RMAN will mark the deleted backups as EXPIRED, but their records are not removed from the catalog automatically, this is because some DBA might move these backups back to the original destination at a later time. Their status will be back to AVAILABLE again.

Now, the database knows that the space is freed up, it should be no more ORA-00257. If the database is still unresponsive, you can decide to delete these records.

Delete Expired Archive Logs

Delete the records of non-existent archived log files from the catalog.

RMAN> delete expired archivelog all;

Same procedure can apply to the following error: How to Resolve ORA-19809 Limit Exceeded for Recovery Files

Источник

Понравилась статья? Поделить с друзьями:
  • Error ora 12541 tns no listener
  • Error ora 12505 sql developer что делать
  • Error ora 12170
  • Error ora 12154 tns could not resolve the connect identifier specified
  • Error ora 06519