A special way of migration

Links

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

A special way of migration

A special way of migration

2005-09-28 - By Gogala, Mladen

Reply: << 11 12 13 14 15 16 17

How many active/users/transactions you have in the database? I am running
an OLTP database and in my case, it's not an exaggeration, at least not
by much. Setting the transaction read-only ensures that all reads are
consistent with respect to the certain point in time, usually the moment
just before the transaction has begun. If there are any other transactions
on the database, you need a consistent get, ie a get from the undo segment.
If somebody wants to modify block you're reading, he or she has to copy it
to an undo block. If you have any long-running transactions, as is the
case with billing, you will get a huge amount of undo blocks. Of course, if
your database is mostly read-only, you really can have just few blocks of
undo space. For the most part, doing export with consistent=yes is inviting
those lovely 1555 "snapshot too old" thingies that we all know and love.
Of course, to add insult to the injury, there is a bug in 9.2.0.4 which
can render your export unusable:
2666174 Export in direct path can product a corrupt export file if
ORA-1555 (See ORA-1555.ora-code.com) occurs
So, as far as I am concerned, "consistent=y" amounts to shooting myself in
both feet. You go ahead and use it. Go ahead, make my data.

--
Mladen Gogala
Ext. 121

-- --Original Message-- --
From: Mark Bole [mailto:makbo@(protected)]
Sent: Wednesday, September 28, 2005 1:26 PM
To: ORACLE-L@(protected)
Subject: Re: A special way of migration

You stated that "The whole export will be read into undo segments". You
further stated that setting consistent=y makes "the whole export
'repeatable'". These statements are mis-information.

An export, with or without consistent=y, does not consume previously
unused undo space. (In fact, individual tables are always exported
consistently regardless of the setting). Undo will be read as needed to
create a read-consistent view of the data, just as they would for any
transaction. If there is very little update activity in the database,
then very little undo will need to be read.

I just started up a database and began a consistent=y export.

The export file is over 3 GB in size so far (still running).

Here is the undo usage, clearly it has nothing to do with the size of
the export:

select begin_time, end_time, undoblks from v$undostat;

BEGIN_TIME END_TIME UNDOBLKS
-- ---- ---- ------ -- ---- ---- ------ -- ---- --
2005/09/28 10:14:11 2005/09/28 10:23:06 3
2005/09/28 10:04:11 2005/09/28 10:14:11 18

Gogala, Mladen wrote:

> Unfortunately, it's not a misinformation. With "consistent=y", you will
> have
> SET TRANSACTION READ ONLY as the first statement in the export. What
> does this statement do you can read for yourself in the manual. It
> wasn't an overuse of sarcasm.
>
> As far as logical backup goes, I would tend not to disagree, but it has
> nothing to do with CONSISTENT=YES. This "read consistent export" can only
> ensure consistency with respect to certain point in time if it builds a
> read-consistent image of the database with respect to that point in time.
> You have three guesses to guess which structures are used for building
> such a consistent image.
> So Mark, please read the fine manual before you accuse me of being
> overly sarcastic.
>
> --
> Mladen Gogala
> Ext. 121
>

--
Mark Bole
http://www.bincomputing.com

--
http://www.freelists.org/webpage/oracle-l

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: A special way of migration</TITLE>
</HEAD>
<BODY>

How many active/users/transactions you have in the database? I
am running
 an OLTP database and in my case, it's not an exaggeration, at
least not
 by much. Setting the transaction read-only ensures that all
reads are consistent with respect to the certain point in time, usually the
moment 

just before the transaction has begun. If there are any other
transactions
 on the database, you need a consistent get, ie a get from the
undo segment.
 If somebody wants to modify block you're reading, he or she
has to copy it 
 to an undo block. If you have any long-running transactions,
  as is the
 case with billing, you will get a huge amount of undo blocks.
Of course, if
 your database is mostly read-only, you really can have just
few blocks of
 undo space. For the most part, doing export with consistent
=yes is inviting
 those lovely 1555 "snapshot too old" thingies that
we all know and love.
 Of course, to add insult to the injury, there is a bug in 9.2
.0.4 which
 can render your export unusable:
 2666174         Export in
direct path can product a corrupt export file if 
           
  ORA-1555 (See ORA-1555.ora-code.com) occurs
 So, as far as I am concerned, "consistent=y" amounts
to shooting myself in both feet. You go ahead and use it. Go ahead, make my
data.

--
 Mladen Gogala
 Ext. 121


-- --Original Message-- --
 From: Mark Bole [<A HREF="mailto:makbo@(protected)">mailto
:makbo@(protected)</A>] 
 Sent: Wednesday, September 28, 2005 1:26 PM
 To: ORACLE-L@(protected)
 Subject: Re: A special way of migration


You stated that "The whole export will be read into undo
segments". You 
 further stated that setting consistent=y makes "the whole
export 
 'repeatable'".   These statements are mis
-information.


An export, with or without consistent=y, does not consume
previously 
 unused undo space. (In fact, individual tables are always
exported 
 consistently regardless of the setting). Undo will be read as
needed to 
 create a read-consistent view of the data, just as they would
for any 
 transaction.  If there is very little update activity in
the database, 
 then very little undo will need to be read.


I just started up a database and began a consistent=y export.


The export file is over 3 GB in size so far (still running).


Here is the undo usage, clearly it has nothing to do with the
size of 
 the export:


select begin_time, end_time, undoblks from v$undostat;


BEGIN_TIME        &nbsp
; END_TIME           
   UNDOBLKS
 -- ---- ---- ------ -- ---- ---- ------ -- ---- --
 2005/09/28 10:14:11 2005/09/28 10:23:06   &nbsp
;      3
 2005/09/28 10:04:11 2005/09/28 10:14:11   &nbsp
;     18


Gogala, Mladen wrote:


> Unfortunately, it's not a misinformation. With &quot
;consistent=y", you will 
 > have
 > SET TRANSACTION READ ONLY as the first statement in the
export. What 
 > does this statement do you can read for yourself in the
manual. It 
 > wasn't an overuse of sarcasm.
 > 
 > As far as logical backup goes, I would tend not to
disagree, but it has 
 > nothing to do with CONSISTENT=YES. This "read
consistent export" can only
 > ensure consistency with respect to certain point in time
if it builds a
 > read-consistent image of the database with respect to
that point in time.
 > You have three guesses to guess which structures are used
for building
 > such a consistent image.
 > So Mark, please read the fine manual before you accuse me
of being 
 > overly sarcastic.
 > 
 > -- 
 > Mladen Gogala
 > Ext. 121
 > 

 

-- 
 Mark Bole
 <A HREF="http://www.bincomputing.com" TARGET="_blank">http:/
/www.bincomputing.com</A>

 
 

--
 <A HREF="http://www.freelists.org/webpage/oracle-l" TARGET="
_blank">http://www.freelists.org/webpage/oracle-l</A>


</BODY>
</HTML>