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: fetch across commit

Goulet, Dick

2004-11-30

Replies:
Ganesh,

 The answer is yes and no. According to the SQL standard once a
commit is issues all open cursors are invalid & need reopening. Oracle,
being the NICE dbms that it is allows us to do otherwise. The problem
is that the current SCN of your session is no longer the same as that of
your cursor and you've released all interest in rollback segments before
the now current scn. Although it is much more common to have the
problem caused by a second session updating the cursor table, the insert
table can also be affected. Delayed Block Cleanout is one potential
culprit, the second can become a integrity constraint check or an index
update or some other matter. OTS has at one time pointed me to a data
dictionary update as the problem. Namely if you create the insert table
with very small extents then getting that third or fourth extent can
cause the problem. The answer in my case was to create the insert table
with one very large initial extent.


Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Ganesh Raja [mailto:ganesh.raja@(protected)
Sent: Tuesday, November 30, 2004 5:36 AM
To: Goulet, Dick
Cc: Oracle List
Subject: Re: fetch across commit

Goulet,

If you see the OP's Program he is Doing an Insert into a Different
Table and commiting there .. So Why Should he Get a 1555 here or a
Fetch Across Commit.

He will get 1555 Only if another Program is doing Updates to the EMP
table and commiting so often that it wraps the Undo faster than this
Process.

A Fetch Across commit will happen only if the Same Table is Updated
and Commitied in a Cursor Loop ...

Additions and corrections welcome.

Cheers!
Ganesh


On Fri, 26 Nov 2004 21:47:03 -0500, Goulet, Dick <dgoulet@(protected)>
wrote:
> Seems you've asked this question twice now, which means you did not
> understand the answer the first time. OK; the short answer is yes it
> can cause an ORA-1555 error. The reason is that when you opened the
> cursor Oracle captured the current SCN, say 100. You've done several
> updates/inserts/deletes based on the logic of your program and done a
> commit, which changed the SCN to say 105. In doing so you've told
> Oracle that you are no longer interested in any rollback segments
before
> SCN 105, when in fact you are. Immediately that is not a problem, but
> sooner or later part of your cursor will need to recreate a data row
to
> SCN 100 with rollback data. Problem is that you've let it go &
> consequently Oracle cannot create a read consistent view as of SCN 100
&
> you get ORA-01555.
>=20
> One trick I've used rather successfully in the past is to put an
"order
> by" clause on the cursor statement. Order By causes a sort, which
means
> Oracle has to find all of the data that your cursor will need and sort
> it before handing you the first row. Now all of your return rows are
> stored in a temp table in the Temp tablespace & no more rollback or
read
> consistent view activity is needed. It's a hack I'll admit, but one
> that appears to work 90% of the time.=3D20
>=20
> Dick Goulet
> Senior Oracle DBA
> Oracle Certified 8i DBA
> -----Original Message-----
> From: ryan_gaffuri@(protected)
> Sent: Wednesday, November 24, 2004 1:53 PM
> To: zimsbait@(protected)
> Cc: z b
> Subject: Re: fetch across commit
>=20
> yes, because a commit releases the lock on the rollback segments and
> orac=3D3D
> le can overwrite them with another process.=3D3D20
> -------------- Original message --------------=3D3D20
>=20
> > Listers,=3D3D20
> >=3D3D20
> > I have a question where I need a little clarification about fetching
> ac=3D3D
> ross=3D3D20
> > commits. Can this happen if the table being committed to is not the
> sam=3D3D
> e=3D3D20
> > as the tables(s) in the cursors?=3D3D20
> >=3D3D20
> > For example, if I had :=3D3D20
> > cursor c1 is select empname form emp where=3D3D20
> > dept =3D3D3D 100;=3D3D20
>=20
>=20
>=20
> --
> http://www.freelists.org/webpage/oracle-l
> --
> http://www.freelists.org/webpage/oracle-l
> --
> http://www.freelists.org/webpage/oracle-l
>
--
http://www.freelists.org/webpage/oracle-l