Home
All Oracle Error Codes
Oracle DBA Forum

Frequent Oracle Errors

TNS:could not resolve the connect identifier specified
Backtrace message unwound by exceptions
invalid identifier
PL/SQL compilation error
internal error
missing expression
table or view does not exist
end-of-file on communication channel
TNS:listener unknown in connect descriptor
insufficient privileges
PL/SQL: numeric or value error string
TNS:protocol adapter error
ORACLE not available
target host or object does not exist
invalid number
unable to allocate string bytes of shared memory
resource busy and acquire with NOWAIT specified
error occurred at recursive SQL level string
ORACLE initialization or shutdown in progress
archiver error. Connect internal only, until freed
snapshot too old
unable to extend temp segment by string in tablespace
Credential retrieval failed
missing or invalid option
invalid username/password; logon denied
unable to create INITIAL extent for segment
out of process memory when trying to allocate string bytes
shared memory realm does not exist
cannot insert NULL
TNS:unable to connect to destination
remote database not found ora-02019
exception encountered: core dump
inconsistent datatypes
no data found
TNS:operation timed out
PL/SQL: could not find program
existing state of packages has been discarded
maximum number of processes exceeded
error signaled in parallel query server
ORACLE instance terminated. Disconnection forced
TNS:packet writer failure
see ORA-12699
missing right parenthesis
name is already used by an existing object
cannot identify/lock data file
invalid file operation
quoted string not properly terminated

RE: Metalink and availability

MVE

2006-05-26

Replies:
--- Jeremiah Wilton <jeremiah@(protected):

> The thing that takes the most time with the CPU patches on Unix is that
> Opatch patches and relinks one binary at a time serially. Having the
> database down is completely unnecessary for many of these binaries, such as
> sqlplus etc. Furthermore, even running binaries like oracle and tnslsnr can
> be relinked with the databases open and running, and staged as alternately
> named files (oracle-new, tnslsnr-new). You can then move them all into
> place during a very brief outage for all instances.
>
> There are a number of tricks that you can use to greatly reduce the apply
> time for the CPU patches. Start with the one-off patch apply guidelines in
> my paper:
>
> http://www.ora-600.net/articles/stayinalive.pdf
>

Jeremiah,

Thanks for a good write up! I also enjoined reading your "The DBA Disaster
Diary: Double Failure" story -- I can relate ...

I had a concern about patching ORACLE_HOME while the instance is running (as
described in your article by modifying patch scripts and oracle make-files). I
think that replacing shared libraries that oracle binaries depend on might
cause some side-effects on the running instance(s). It's also not supported as
the patch clearly states that all processes must be down.

Instead, I would suggest to pre-stage a copy of patched ORACLE_HOME that was
built on a different server, shutdown all running instances and quickly switch
ORACLE_HOMEs then apply DB portion of the upgrade (if any). So far ORACLE has
been good at separating DATABASE portion of the upgrade from the SOFTWARE.

I am an APPS DBA (97%) and have used similar technique for staging APPS
APPL_TOPs and APPS tech-stack (tools ORACLE_HOMEs) during major upgrades. We'd
stage the software ahead of time then ONLY run the database portion (d drivers)
of the upgrade thus reducing the total upgrade time. Still, in the APPS
"world" major upgrades take 40-60 *continuous* hours. That's why I wouldn't
recommend running APPS in "front" of a true 24/7/365 shop (back-end is OK maybe
...). You just can't turn replication ON on something like this:

14:59:41 SYSTEM@(protected)
14:59:46  2 from dba_objects
14:59:50  3 group by object_type
14:59:53  4 order by 1 desc;

COUNT(*) OBJECT_TYPE
---------- ------------------
  45979 SYNONYM
  37683 INDEX
  37046 PACKAGE
  35940 PACKAGE BODY
  26436 VIEW
  21359 TABLE
  10095 JAVA CLASS
   8759 SEQUENCE
   2588 TRIGGER
   1457 TYPE
    933 INDEX PARTITION
    575 LOB
    438 TABLE PARTITION
    412 MATERIALIZED VIEW
    290 JAVA DATA
    209 PROCEDURE
    197 JAVA RESOURCE
    164 FUNCTION
    143 QUEUE
    85 LIBRARY
    71 TYPE BODY
    61 DATABASE LINK
    46 RULE SET
    27 OPERATOR
    25 EVALUATION CONTEXT
    20 CONTEXT
    20 RULE
    10 CLUSTER
     8 JAVA SOURCE
     7 INDEXTYPE
     4 CONSUMER GROUP
     3 DIRECTORY
     3 RESOURCE PLAN

15:09:01 SYSTEM@(protected))
mbytes,segment_type
15:09:32  2 from dba_segments
15:09:35  3 group by segment_type;

  MBYTES SEGMENT_TYPE
---------- ------------------
     0 CACHE
    158 CLUSTER
  55514 INDEX
    133 INDEX PARTITION
    22 LOBINDEX
    773 LOBSEGMENT
     0 ROLLBACK
     8 SPACE HEADER
  63907 TABLE
    313 TABLE PARTITION
    83 TYPE2 UNDO

## with so many (2706) transactions per hour (slow day)
##
amanda.XUPG-> grep "26-MAY-2006 14" xupg.log | wc -l
  2706

Regards,
- Vitaliy
--
http://www.freelists.org/webpage/oracle-l