FranklinFaces.com - Oracle & SQL Server Database Forums for all IT Professionals / Oracle Forum / ORA - Oracle Database Error Codes - Search via specific error codes. / ORA-10560 Through ORA-19999

ora 12012 ORA-12012: error on auto execute of job 101

Admin — Tue, 15 Jun 2010 10:58:37 GMT

ORA-12012: error on auto execute of job 101

ORA-12005: may not schedule automatic refresh for times in the past

I see Errors in my alert log , and these errors are generated every 5 minutes. It seems to be that some PL/SQL Block under SYSTEM is throwing these errors.

here is the error message in alert log.
++++++++++++++++++++++++++++++++++
Fri Feb 27 10:04:17 2009
Errors in file /u10/app/ORACLE/admin/dss/bdump/dss_j000_12401.trc:
ORA-12012: error on auto execute of job 144338
ORA-06550: line ORA-06550: line 1, column 531:
PL/SQL: ORA-00917: missing comma
ORA-06550: line 1, column 439:
PL/SQL: SQL Statement ignored
, column :
Fri Feb 27 10:09:17 2009
Errors in file /u10/app/ORACLE/admin/dss/bdump/dss_j000_12515.trc:
ORA-12012: error on auto execute of job 144338
ORA-06550: line ORA-06550: line 1, column 531:
PL/SQL: ORA-00917: missing comma
ORA-06550: line 1, column 439:
PL/SQL: SQL Statement ignored
, column :
+++++++++++++++++++++++++++++++++++++

I looked up into one of those TRACE file that it refers in ALERT LOG
---------------------------------------------------------------------------------------------
/u10/app/ORACLE/admin/dss/bdump/dss_j000_12515.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u10/app/ORACLE/product/10.2.0.1
System name: SunOS
Node name: oscora02z
Release: 5.10
Version: Generic_127127-11
Machine: sun4u
Instance name: dss
Redo thread mounted by this instance: 1
Oracle process number: 20
Unix process pid: 12515, image: oracle@oscora02z (J000)

*** ACTION NAME:(JOB_SNAP_TEMP_USAGE) 2009-02-27 10:09:17.131
*** MODULE NAME:(DBMS_SCHEDULER) 2009-02-27 10:09:17.131
*** SERVICE NAME:(SYS$USERS) 2009-02-27 10:09:17.131
*** SESSION ID:(312.17680) 2009-02-27 10:09:17.131
*** 2009-02-27 10:09:17.131
ORA-12012: error on auto execute of job 144338
ORA-06550: line ORA-06550: line 1, column 531:
PL/SQL: ORA-00917: missing comma
ORA-06550: line 1, column 439:
----------------------------------------------------------------------------------------------

So my question is , why is this 'JOB_SNAP_TEMP_USAGE' runnign every 5 minutes. How do i disable it or what happens, if i delete this JOB ?

ORA-12853: insufficient memory for PX buffers: current stringK, max needed stringK

Admin — Tue, 15 Jun 2010 09:31:10 GMT

ora error code

ORA-12853:	insufficient memory for PX buffers: current stringK, max needed stringK
Cause:	Insufficient SGA memory for PX buffers
Action:	Reconfigure sga to include at least (max - current) bytes of additional memory

ora error code ORA-12162: TNS:net service name is incorrectly specified

Admin — Mon, 14 Jun 2010 16:41:13 GMT

ora error

ORA-12162:

TNS:net service name is incorrectly specified

ORA-12162:	TNS:net service name is incorrectly specified
Cause:	The connect descriptor corresponding to the net service name in TNSNAMES.ORA or in the directory server (Oracle Internet Directory) is incorrectly specified.
Action:	If using local naming make sure there are no syntax errors in the corresponding connect descriptor in the TNSNAMES.ORA file. If using directory naming check the information provided through the administration used for directory naming.

ORA-12537: TNS:connection closed - TNS-12535: TNS:operation timed out ora error

Admin — Tue, 01 Dec 2009 01:39:56 GMT

I got this ora error message when a user pointed it out to me that they can't connect to database using TOAD.

ORA-12537: TNS:connection closed

I asked the user to send me more info and that's all he was able to provide. I noticed in the sqlnet.ora the following :

Fatal NI connect error 12170.

VERSION INFORMATION:
TNS for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Production
TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Production
Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Production
Time: 30-NOV-2009 14:55:06
Tracing not turned on.
Tns error struct:
ns main err code: 12535
TNS-12535: TNS:operation timed out
ns secondary err code: 12560
nt main err code: 505
TNS-00505: Operation timed out
nt secondary err code: 78
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=120.12.214.2)(PORT=1521))

I restarted the listener and that didn't help either. Then i logged into the database and noticed that there were 396 connections to the database and the processes parameter was set to 400.

I had to open emergency ticket to recycle the production database to change the value to 900 from 400 and restarted the database.

This fixed the problem and user was able to connect and i stopped seeing those errors.

Hope this helps.

Thanks,

ORA-16038: alter database open" ORA-16038 ORA-19809 ORA-00312 errors

Admin — Fri, 24 Apr 2009 15:57:17 GMT

Hi,

I'm getting the following error message when starting up the database:

OS: SUN Solaris 5.10 DB: 10.2.0.3 USING ASM

SQL> startup
ORACLE instance started.

Total System Global Area 2634022912 bytes
Fixed Size 2130720 bytes
Variable Size 513637600 bytes
Database Buffers 2113929216 bytes
Redo Buffers 4325376 bytes
Database mounted.
ORA-16038: log 2 sequence# 1704 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 2 thread 1:
'+SHARED_DATA_DG02/proddb/onlinelog/group_2.257.681318315'
ORA-00312: online log 2 thread 1:
'+SHARED_DATA_DG03/proddb/onlinelog/group_2.263.681321803'

I couldn't figure out what to do. I even deleted all the archivelogs from RMAN:

RMAN> delete noprompt archivelog all;

released channel: ORA_DISK_1
released channel: ORA_DISK_2
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=64 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=163 devtype=DISK
specification does not match any archive log in the recovery catalog

I then checked the recovery area:

SQL> show parameter recovery

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +SHARED_FRA_DG01
db_recovery_file_dest_size big integer 2G
recovery_parallelism integer 0

After checking this, I knew what my problem was. The db_recovery_file_dest_size is set to 2G. When i had created my spfile, i had set it to 200G, but this time, I had started it with the init<sid>.ora file and the initfile had it set to 2G and the archiver had been stuck. I changed it by issuesing the following command:

SQL> alter system set db_recovery_file_dest_size=200G scope=both;

System altered.

Then i shutdown the db and started it up again:

SQL> shutdown immediate;
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Hope this helps.

Ora Error : ORA-16401: archivelog rejected by RFS

Admin — Tue, 08 Sep 2009 15:57:18 GMT

Ora Error : ORA-16401: archivelog rejected by RFS

Cause: An attempt was made to re-archive an existing archivelog. This usually happens because either a multiple primary database or standby database(s) or both are trying to archive to this standby database.

Action: See alert log and trace file for more details. No action is necessary; this is an informational statement provided to record the event for diagnostic purposes.

ORA-16401 may be signalled incorrectly due to existence of
a remote entry, but not a local one. (RFS rejects the log)

Workaround:
Manually register the log entry using "register or replace"
option from the primary (alter database register or replace logfile ..)

This is related to a bug.

This issue is fixed in

Here is something that I came across regarding RAC and this error message:

Instance crashed after the following error in the alert log file:

ORA-16401: archivelog rejected by RFS
SUCCESS: diskgroup ARCH was dismounted
Thu Jul 30 04:04:38 2009
Errors in file /u01/oracle/admin/prod/bdump/prod_lms1_12658.trc:
ORA-00600: internal error code, arguments: [504], [0x060011DA8], [80], [6], [mostly latch-free
SCN], [0], [0], [0x06000F408]
Thu Jul 30 04:04:40 2009
Errors in file /u01/oracle/admin/prod/bdump/prod_lms1_12658.trc:
ORA-00600: internal error code, arguments: [600], [], [], [], [], [], [], []

In the trace file:

----- Call Stack Trace -----
ksl_level_check kslgetl kcsadj1 kcmclscn ksxpwait kslwaitns kskthbwt kslwait kmgs_sleep_wait
kmgs_create_request kmgs_immediate_req ksmasg kghnospc kghalo ksmdacnk ksmdget kjbrextend
kjbralc kjbopen kclexpand kclobj kclaoliter

Cause

The cause of this problem has been identified and verified in an unpublished Bug 4466106:
the ORA-600 [504] [mostly latch-free SCN] can occur on some platforms in a RAC environment. Trace
files for the ORA-600 [504] will show the failing process holding one of the latches below at level 6:

KJC message pool free list
gcs opaque info freelist
gcs resource freelist
gcs shadows freelist

Also Bug 4997495 reports the ORA-600 [504] [mostly latch-free SCN] where the failing process hold other latches:

name-service request queue
name-service pending queue
name-service namespace bucket
name-service memory objects
name-service namespace objects
name-service request

Solution

1. apply oneoff Patch 4466106 on top of 10.2.0.1 release if available for your platform

2. or apply 10.2.0.3 patchset where Bug 4997495 is fixed and then request the oneoff patch for
the unpublished Bug 4466106 (as fixed in 11.1.0.6).

3. or upgrade to 11.1.0.6 release where both bugs are fixed.

ORA-16721: unable to set LOG_ARCHIVE_DEST_n parameters ora error

Admin — Tue, 08 Sep 2009 14:45:29 GMT

ORA-16721: unable to set LOG_ARCHIVE_DEST_n parameters

Cause: An attempt of setting some of the LOG_ARCHIVE_DEST_nparameters failed.

Action: Check the Data Guard broker log and database alert logs for further details.

Please add more information about this ora Error

ORA-12560: TNS protocol adapter error ora error

Admin — Tue, 23 Jun 2009 17:02:16 GMT

Hi,

When i'm trying to sqlplus '/ as sysdba' , i'm getting the following ora error message:

# sqlplus '/ as sysdba'

SQL*Plus: Release 9.2.0.7.0 - Production

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Enter user-name: / as sysdba
ERROR:
ORA-12560: TNS:protocol adapter error

Anyone know what to do? I tried all over the internet to search for the solution but couldn't find a solid one.

Thanks,

ORA-15036: disk '/oracle/devices/asm_data_002' is truncated ora error message

Admin — Wed, 20 May 2009 15:19:20 GMT

I was getting the following ora error and I couldn't drop the diskgroup. It was so frustrating cuz i couldn't figure out why.

Go through this post throughly to see the fix for it. Also, make sure if you have data on that disk to BE CAREFUL!!! If you want to loose the data then only follow these steps. In my case, it was brand new install so I really didn't care as long as my ASM instance was able to see the disk correctly.

SQL> alter diskgroup SHARED_DATA_DG01 mount;
alter diskgroup SHARED_DATA_DG01 mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15036: disk '/oracle/devices/asm_data_002' is truncated

I queried the ASM instance and found something weird. Look ath the second diskgroup. Everything is 0 and File Size has nothing.

SQL> SELECT name, type, total_mb, free_mb, required_mirror_free_mb,usable_file_mb FROM V$ASM_DISKGROUP;

NAME TYPE File Size (MB) FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
------------------------------ ------ -------------- ---------- ----------------------- --------------
SHARED_AUXFILES_DG01 EXTERN 714,752 714696 0 714696
SHARED_DATA_DG01 0 0 0 0
SHARED_FRA_DG01 EXTERN 28,672 28622 0 28622
--------------
Grand Total: 743,424

So then this baffled me and I went to look at the disks by issuing the following commands.

SQL> set linesize 200

SQL> col path format a65

SQL> SELECT name, header_status, path FROM V$ASM_DISK;

NAME HEADER_STATU PATH
------------------------------ ------------ ----------------------------------------
MEMBER /oracle/devices/asm_data_002
CANDIDATE /oracle/devices/asm_data_003
SHARED_AUXFILES_DG01_0000 MEMBER /oracle/devices/asm_data_001
SHARED_FRA_DG01_0000 MEMBER /oracle/devices/asm_fra_001

This was even more weird now because my diskgroup doesn't show up and one of the disk now shows that it's a member of no diskgroup name. This is totally weird. Then I went onto metalink and i saw an article on there. DOC ID: 553319.1 There is a command that they have which you can use to verify the disk size and compare it to what should be on the OS size. The command is kfed. ( like briney's ex ) :) If you don't have kfed, you can compile it as below:

# which kfed

# no kfed in

/bin /oracle/dba/local /usr/local/bin /usr/bin /usr/ccs/bin /usr/ucb /etc /usr/sbin /sbin /usr/dt/bin /usr/lpp/X11/bin /opt/bin /usr/lbin /usr/bin/X11

To make kfed do following:

# cd $ORACLE_HOME/rdbms/lib

# make -f ins_rdbms.mk ikfed

After running the make command, you can issue the following against the disk with issues:

# kfed read /dev/vx/rdsk/asm_dg/asm_dg_002

kfbh.endian: 0 ; 0x000: 0x00
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 563600374 ; 0x00c: 0x2197dbf6
kfbh.fcn.base: 6603 ; 0x010: 0x000019cb
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000
kfdhdb.compat: 168820736 ; 0x020: 0x0a100000
kfdhdb.dsknum: 0 ; 0x024: 0x0000
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: SHARED_DATA_DG01_0000 ; 0x028: length=21
kfdhdb.grpname: SHARED_DATA_DG01 ; 0x048: length=16
kfdhdb.fgname: SHARED_DATA_DG01_0000 ; 0x068: length=21
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32909522 ; 0x0a8: HOUR=0x12 DAYS=0x6 MNTH=0xa YEAR=0x7d8
kfdhdb.crestmp.lo: 2203590656 ; 0x0ac: USEC=0x0 MSEC=0x208 SECS=0x35 MINS=0x20
kfdhdb.mntstmp.hi: 32917794 ; 0x0b0: HOUR=0x2 DAYS=0x9 MNTH=0x2 YEAR=0x7d9
kfdhdb.mntstmp.lo: 1437176832 ; 0x0b4: USEC=0x0 MSEC=0x265 SECS=0x1a MINS=0x15
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 512000 ; 0x0c4: 0x0007d000
kfdhdb.pmcnt: 6 ; 0x0c8: 0x00000006
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]: 65535 ; 0x0da: 0xffff
kfdhdb.redomirrors[2]: 65535 ; 0x0dc: 0xffff
kfdhdb.redomirrors[3]: 65535 ; 0x0de: 0xffff
kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 32909522 ; 0x0e4: HOUR=0x12 DAYS=0x6 MNTH=0xa YEAR=0x7d8
kfdhdb.grpstmp.lo: 2203507712 ; 0x0e8: USEC=0x0 MSEC=0x1b7 SECS=0x35 MINS=0x20
kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0x00000000
kfdhdb.ub4spare[1]: 0 ; 0x0f0: 0x00000000
kfdhdb.ub4spare[2]: 0 ; 0x0f4: 0x00000000
kfdhdb.ub4spare[3]: 0 ; 0x0f8: 0x00000000
kfdhdb.ub4spare[4]: 0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[5]: 0 ; 0x100: 0x00000000
kfdhdb.ub4spare[6]: 0 ; 0x104: 0x00000000
kfdhdb.ub4spare[7]: 0 ; 0x108: 0x00000000
kfdhdb.ub4spare[8]: 0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[9]: 0 ; 0x110: 0x00000000
kfdhdb.ub4spare[10]: 0 ; 0x114: 0x00000000
kfdhdb.ub4spare[11]: 0 ; 0x118: 0x00000000
kfdhdb.ub4spare[12]: 0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[13]: 0 ; 0x120: 0x00000000
kfdhdb.ub4spare[14]: 0 ; 0x124: 0x00000000
kfdhdb.ub4spare[15]: 0 ; 0x128: 0x00000000
kfdhdb.ub4spare[16]: 0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[17]: 0 ; 0x130: 0x00000000
kfdhdb.ub4spare[18]: 0 ; 0x134: 0x00000000
kfdhdb.ub4spare[19]: 0 ; 0x138: 0x00000000
kfdhdb.ub4spare[20]: 0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[21]: 0 ; 0x140: 0x00000000
kfdhdb.ub4spare[22]: 0 ; 0x144: 0x00000000
kfdhdb.ub4spare[23]: 0 ; 0x148: 0x00000000
kfdhdb.ub4spare[24]: 0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[25]: 0 ; 0x150: 0x00000000
kfdhdb.ub4spare[26]: 0 ; 0x154: 0x00000000
kfdhdb.ub4spare[27]: 0 ; 0x158: 0x00000000
kfdhdb.ub4spare[28]: 0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[29]: 0 ; 0x160: 0x00000000
kfdhdb.ub4spare[30]: 0 ; 0x164: 0x00000000
kfdhdb.ub4spare[31]: 0 ; 0x168: 0x00000000
kfdhdb.ub4spare[32]: 0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[33]: 0 ; 0x170: 0x00000000
kfdhdb.ub4spare[34]: 0 ; 0x174: 0x00000000
kfdhdb.ub4spare[35]: 0 ; 0x178: 0x00000000
kfdhdb.ub4spare[36]: 0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[37]: 0 ; 0x180: 0x00000000
kfdhdb.ub4spare[38]: 0 ; 0x184: 0x00000000
kfdhdb.ub4spare[39]: 0 ; 0x188: 0x00000000
kfdhdb.ub4spare[40]: 0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[41]: 0 ; 0x190: 0x00000000
kfdhdb.ub4spare[42]: 0 ; 0x194: 0x00000000
kfdhdb.ub4spare[43]: 0 ; 0x198: 0x00000000
kfdhdb.ub4spare[44]: 0 ; 0x19c: 0x00000000
kfdhdb.ub4spare[45]: 0 ; 0x1a0: 0x00000000
kfdhdb.ub4spare[46]: 0 ; 0x1a4: 0x00000000
kfdhdb.ub4spare[47]: 0 ; 0x1a8: 0x00000000
kfdhdb.ub4spare[48]: 0 ; 0x1ac: 0x00000000
kfdhdb.ub4spare[49]: 0 ; 0x1b0: 0x00000000
kfdhdb.ub4spare[50]: 0 ; 0x1b4: 0x00000000
kfdhdb.ub4spare[51]: 0 ; 0x1b8: 0x00000000
kfdhdb.ub4spare[52]: 0 ; 0x1bc: 0x00000000
kfdhdb.ub4spare[53]: 0 ; 0x1c0: 0x00000000
kfdhdb.ub4spare[54]: 0 ; 0x1c4: 0x00000000
kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[57]: 0 ; 0x1d0: 0x00000000
kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000
kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000
kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000
kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000

Take the two numbers in red above and multiply it: 1048576 x 512000 = 53,687,0912,000. This should be the size of your disk. This is how oracle recognizes it. Remember, don't use this command unless you absolutely exhausted all other options. Talk to oracle because they say that this command might damage your disks. :) Careful.

Anyhow, for me it matched fine. So i saw another article and tought to give it a try. It was asking me to write to the diskgroup by cleaning it up using this command:

dd if=/dev/zero of=/dev/vx/rdsk/asm_dg/asm_dg_002 bs=1024k count=100

100+0 records in
100+0 records out

That one solved my problem. If you still have issues, i suggest you now contact your SA and have them reformat your disks and fix it on their end.

SQL>
SQL> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup
ASM instance started

Total System Global Area 700448768 bytes
Fixed Size 2032736 bytes
Variable Size 673250208 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted
SQL> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown

Good luck. Hope this helped you out.

Do reply and let me know if this helped you out.

=====================================================================

ORACLE'S CODE:

ORA-15036: disk "string" is truncated

Cause: The size of the disk, as reported by the operating system, was smaller than

the size of the disk as recorded in the disk header block on the disk.

Action: Check if the system configuration has changed.

Thanks,

ORA-16009: remote archive log destination must be a STANDBY database ora error

stacyliang83 — Tue, 05 May 2009 10:58:07 GMT

I'm in a weird situation. The dba before i joined this company setup the dataguard environment and although it's applying the logs successfully, I see these messages in the alert log. It's annoying.

PRIMARY:

Tue May 5 10:47:10 2009
RFS: Possible network disconnect with primary database
RFS: Destination database mount ID mismatch [0x9a40bd93:0x9a5d198b]
RFS: client instance is standby database instead of primary
RFS: Not using real application clusters
Tue May 5 10:53:10 2009
RFS: Possible network disconnect with primary database
RFS: Destination database mount ID mismatch [0x9a40bd93:0x9a5d198b]
RFS: client instance is standby database instead of primary
RFS: Not using real application clusters

STANDBY:

Errors in file /u01/oradba/admin/PRDSTDBY/bdump/PRDSTDBY_arc0_14447.trc:
ORA-16009: remote archive log destination must be a STANDBY database
Media Recovery Log /u01/oradba/admin/PRDSTDBY/arch/PRDSTDBY_T1_S75345.arc
Media Recovery Waiting for thread 1 seq# 75346
Tue May 5 09:48:08 2009
Errors in file /u01/oradba/admin/PRDSTDBY/bdump/PRDSTDBY_arc0_14447.trc:
ORA-16009: remote archive log destination must be a STANDBY database
Tue May 5 09:54:08 2009
Errors in file /u01/oradba/admin/PRDSTDBY/bdump/PRDSTDBY_arc0_14447.trc:
ORA-16009: remote archive log destination must be a STANDBY database
Tue May 5 10:00:08 2009

Can't seem to figure it out. Any help is appreciated.

ORA-12705: Cannot access NLS data files or invalid environment specified

Admin — Tue, 07 Apr 2009 14:45:57 GMT

I'm getting the following ora error message:

ERROR:
ORA-12705: Cannot access NLS data files or invalid environment specified

When logging into oracle using sqlplus:

sqlplus '/ as sysdba';

Message 133 not found; product=SQLPlus; facility=SP2
: Release 9.2.0.6.0 - Production on Tue Apr 7 14:20:15 2009

ERROR:
ORA-12705: Cannot access NLS data files or invalid environment specified

oerr ora 12705 shows the following:

12705, 00000, "Cannot access NLS data files or invalid environment specified"
// *Cause: Either an attempt was made to issue an ALTER SESSION command
// with an invalid NLS parameter or value; or the environment
// variable(s) NLS_LANG, ORA_NLSxx, or ORACLE_HOME was incorrectly
// specified, therefore the NLS data files cannot be located.
// *Action: Check the syntax of the ALTER SESSION command and the NLS
// parameter, correct the syntax and retry the statement, or
// specify the correct directory path/values in the environment
// variables.

In my case this was very easy. My ORACLE_HOME was set to /u01/oracle/product/9.2.0.6 instead of /u01/oracle/product/10.2.0.3. Once I corrected that it went through just fine. But that may not be the only cause of this error.

Check that any of the following is true:

NLS_LANG parameter is correct or any other ORA_NLSxx is correct.

ORACLE_HOME parameter is set correct.

Check to see that you are in the correct $ORACLE_HOME during migration etc..

You can use the unset command in unix to unset your parameter or simply set/export them again.

ORA-12519: TNS:no appropriate service handler found tips

Admin — Thu, 19 Mar 2009 03:30:28 GMT

Users were getting the following ora error messages and I noticed the the listener.log had some entries that showed the state=blocked. Here are my findings and solution.

Users are getting below errors in their app logs connecting to the database.

Error Message: MYPRODDB Io exception: Connection refused (DESCRIPTION= (TMP=) (VSNNUM=153093632)(ERR=12519)(ERROR_STACK=(ERROR=(CODE=12519)

(EMFI=4))))

tabase: java.sql.SQLException: Io exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153093632)(ERR=12519)(ERROR_STACK=(ERROR=(CODE=12519)(EMFI=4))))

2009-03-18 23:04:25,175 ERROR - 18/3/2009 23:4:25 || merx.toolkit.DBWithoutPooling:newConnection():Io exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153093632)(ERR=12519)(ERROR_STACK=(ERROR=(CODE=12519)(EMFI=4))))

2009-03-18 23:04:25,175 ERROR - 18/3/2009 23:4:25 || cl***merx.toolkit.DBWithoutPooling:newStatement()->merx.toolkit.DBException: Cannot connect to Database: java.sql.SQLException: Io exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153093632)(ERR=12519)(ERROR_STACK=(ERROR=(CODE=12519)(EMFI=4))))

2009-03-18 23:04:45,740 ERROR - 18/3/2009 23:4:45 || merx.toolkit.DBWithoutPooling:newConnection():Io exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153093632)(ERR=12519)(ERROR_STACK=(ERROR=(CODE=12519)(EMFI=4))))

2009-03-18 23:04:45,740 ERROR - 18/3/2009 23:4:45 || cl***merx.toolkit.DBWithoutPooling:newStatement()->merx.toolkit.DBException: Cannot connect to Database: java.sql.SQLException: Io exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153093632)(ERR=12519)(ERROR_STACK=(ERROR=(CODE=12519)(EMFI=4))))

2009-03-18 23:04:45,806 ERROR - 18/3/2009 23:4:45 || merx.toolkit.DBWithoutPooling:newConnection():Io exception: Connection refused(DESCRIPTION=(TMP=)(VSNNUM=153093632)(ERR=12519)(ERROR_STACK=(ERROR=(CODE=12519)(EMFI=4))))

I checked the listener.log and this is what it showed:

TNS-12519: TNS:no appropriate service handler found
18-MAR-2009 23:47:45 * (CONNECT_DATA=(SID=MYPRODDB)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp)(HOST=prodserv1)(PORT=42121)) * establish * MYPRODDB * 12519
TNS-12519: TNS:no appropriate service handler found
18-MAR-2009 23:47:45 * (CONNECT_DATA=(SID=MYPRODDB(CID=(PROGRAM=)(HOST=__jdbc__)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp)(HOST=prodserv1)(PORT=42122)) * establish * MYPRODDB * 12519
TNS-12519: TNS:no appropriate service handler found
18-MAR-2009 23:47:45 * (CONNECT_DATA=(SID=MYPRODDB)(CID=(PROGRAM=)(HOST=__jdbc__)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp)(HOST=prodserv1)(PORT=42123)) * establish *

I did a status on the listener and this is what showed that the status is blocked:

Service "MYPRODDB" has 1 instance(s).
Instance "MYPRODDB", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:16610866 refused:0 state:blocked
LOCAL SERVER

So after doing some research, I found out that the database didn't register with the listener and that the processes parameter needed to be increased. So did the following two things:

SQL> alter system set processes=500 scope=spfile;

SQL> alter system register;

After i issued these two statements and checked the listener status I saw the following:

Service "MYPRODDB" has 1 instance(s).
Instance "MYPRODDB", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:5775993 refused:0 state:ready
LOCAL SERVER

I hope this helps .

Remember, oracle states the following reasons that it maybe in that state:

There are normally 5 reasons for an instance to be blocked:

1.The remote_listener parameter is set in the init/spfile, but the local_listener is not running.
2.The instance is not fully mounted.
3.The instance is shutting down.
4.The maximum number of concurrent sessions has been reached.
5.The node load is at a maximum.

Thanks,

ORA-16057: DGID from server not in Data Guard configuration

JasonHussey — Thu, 16 Oct 2008 08:57:14 GMT

Hi,

I am getting the following error message when setting up oracle streams downstream capture.

ORA-16057: DGID from server not in Data Guard configuration

I have primary ---> going to standby

I have setup primary ----> going to downstream capture.

My primary to standby is working but can't seem to get primary to downstream capture to work and keep getting this message. I've setup the db_unique_name and still can't figure it out. Any one can help?