I partially agree with Mladen.
RMAN definitely doesn't identify Table HWMs -- it doesn't know logical
structures such as Tables and Segments and Tablespaces [although it
can assist you in Tablespace Recovery when it reads the Data Dictionary].
RMAN knows physical structures such as DataFiles, RedoLog Files and
ControlFiles. When backing up a DataFile, RMAN would ignore
__unused__ blocks --- blocks that have never been used.
Now, the part where I don't agree with Mladen is about reading the
bitmap information from the tablespace header. RMAN can backup
DataFiles belonging to Dictionary Managed Tablespaces without
Automatic Segment Space Management. In such cases there is no
bitmap in the tablespace header to read from.
When Oracle creates a DataFile it initializes the file with NULLs. When
a block is used [written to as a Table Row-Block or an Index Leaf-Block],
the block has to be formatted before it is written-to. Once it is formatted
[the formatting is the block header, table column names, and possibly
the initrans area and pctfree area], the block will always remain "used"
even if all the rows in it are deleted.
Thus, when RMAN goes through a DataFile it examines each block and
ignores unused blocks which have not been formatted.
Such unused or empty blocks may be within an Extent or unallocated to any
extent !
Hemant
At 08:13 AM 04-04-03 -0800, you wrote:
What it doesn't write are the blocks that are not allocated to any
extent. RMAN doesn't go into the logical structures, like tables and
indexes,
it looks into the tablespace header and reads the information from the
bitmap information there. It cannot go into tables/indexes because it
should also work when the database is only mounted and not opened, which
genrally means that data dictionary is not accessible. Empty blocks
are blocks that don't have any rows in them but are allocated to an
extent. New or unallocated blocks are blocks that have been initialized
when the datafile was allocated to the tablespace but have not been assigned
to any object (table, index, materialized view, cluster, partition or alike)
-Original Message-
Sent: Thursday, April 03, 2003 4:24 PM
To: Multiple recipients of list ORACLE-L
Actually this is how RMAN works. It writes all blocks up to the HWM of a
given table,
even empty ones. So, if your HWM is artifically high, you will encounter
backups
that are larger than they need to be.
Oracle9i RMAN Backup and Recovery On bookshelves now!
RF
-Original Message-
To: Multiple recipients of list ORACLE-L
Sent: 4/3/2003 11:19 AM
Keith
Here is my understanding (don't rely on this one). When Oracle
allocates
tablespace, the disk blocks are cleared. My interpretation is that when
RMAN
encounters a clear block, it doesn't write it to the backup piece. I
don't
think it spends a lot of time trying to figure out above HWM and such.
Dennis Williams
DBA, 40%OCP, 100% DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-Original Message-
Sent: Thursday, April 03, 2003 10:44 AM
To: Multiple recipients of list ORACLE-L
Our RMAN backup is backing up much more than the actual data blocks when
doing a full backup. I know that it backs up all blocks that have "ever
been
used", but I'm trying to figure out exactly what that means. My first
thought was that it backs up all blocks below the HWM, but I analyzed
the
tables and that is not the case.
Sometimes it backs up more blocks than exist below the HWM for the
tables
and sometimes it backs up fewer blocks than those below the HWM.
We are doing this to determine what we can do to reduce the size of the
backup.
Anyone have an idea how this works?
Keith
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Freeman Robert - IL
INET: [EMAIL PROTECTED]
Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L F
