Re: student question: incremental backups (level 0 and level 1)

From: joel garry <joel-garry_at_home.com>
Date: Thu, 26 Jun 2008 11:11:42 -0700 (PDT)
Message-ID: <310faf59-f328-46f3-9c01-fd1fb477167d@34g2000hsf.googlegroups.com>


On Jun 26, 4:16 am, pellicleund..._at_hotmail.com (obakesan) wrote:
> Hi
>
> ok ... things are gradually being revealed ...
>
> In article <lkm664900qskls1v784bq0qug68odsk..._at_4ax.com>, sybra..._at_hccnet.nl
> wrote:
>
> >On Thu, 26 Jun 2008 04:57:54 GMT, pellicleund..._at_hotmail.com
> >(obakesan) wrote:
>
> >>so perhaps a level 0 is as near as damit a full tablespace copy ...
>
> >It is not.
> >'Empty' blocks will not be copied. Empty blocks means blocks without a
> >SCN. A block which has been used at least once has a SCN and will be
> >copied.
>
> so then, does this SCN get updated or invalidated at say a truncate table?
>
> See Ya
> (when bandwidth gets better ;-)
>
> Chris Eastwood
> Photographer, Programmer Motorcyclist and dingbat
> blog:http://cjeastwd.blogspot.com/
>
> please remove undies for reply

Sybrand is right as usual.

http://www.jlcomp.demon.co.uk/faq/blockdump.html

Note you can do things like
SQL> create table jjjjj as select * from all_objects;

Table created.

SQL> connect / as
sysdba
Connected.
SQL> select file_id,block_id from dba_extents where segment_name='JJJJJ';

   FILE_ID BLOCK_ID
---------- ----------

        64      91297
        64      91305
        64      91313
        64      91321
        64      91329
        64      91337
        64      91345
        64      91353
        64      91361
        64      91369
        64      91377

   FILE_ID BLOCK_ID
---------- ----------

        64      91385
        64      91393
        64     122761
        64     122769
        64     122777
        64     121993
        64     122121
        64     122249

19 rows selected.

SQL> connect rossjeg
Enter password:
Connected.
SQL> truncate table jjjjj;

Table truncated.

SQL> connect / as sysdba;
Connected.
SQL> select file_id,block_id from dba_extents where segment_name='JJJJJ';

   FILE_ID BLOCK_ID
---------- ----------

        64 91297

SQL> alter system dump datafile 64 block 122249;

System altered.

Then you can examine the data block in the trace in your user_dump_dest and see that it does indeed have an SCN:

...
*** 2008-06-26 10:55:47.751
*** SESSION ID:(15.3619) 2008-06-26 10:55:47.700 Start dump data blocks tsn: 15 file#: 64 minblk 122249 maxblk 122249 buffer tsn: 15 rdba: 0x1001dd89 (64/122249) scn: 0x0000.1a7c00a8 seq: 0x02 flg: 0x04 tail: 0x00a80602 frmt: 0x02 chkval: 0x8f10 type: 0x06=trans data Block header dump: 0x1001dd89
 Object id on Block? Y
 seg/obj: 0x28d9e csc: 0x00.1a7c0071 itc: 3 flg: - typ: 1 - DATA

     fsl: 0 fnx: 0x0 ver: 0x01
...

I wouldn't know whether this applies in every situation like after a shrink in ASSM...

Richard Foote's blog has (and some other places have) good examples of how to interpret dumps.

jg

--
@home.com is bogus.
"So what do they call this generation that is now between 16 and 27?"
"It's a word that starts with F and ends with D."
"Generation FRED?" - heard on radio
Received on Thu Jun 26 2008 - 13:11:42 CDT

Original text of this message