20171000011301_about rman1_faq .txt, 20171130 rman

20171000011301_about rman1_faq .txt, 20171130 rman

Please refer to 1130.pdf about rman FAQ. txt

-- // The previous test is too messy and some rman as copy tests are re-performed.

1. Environment:
SCOTT @ book> @ & r/ver1
PORT_STRING VERSION BANNER
----------------------------------------------------------------------------------------------------------------------------
X86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0-64bit Production

CREATE TABLESPACE SUGAR DATAFILE
'/Mnt/ramdisk/book/sugar01.dbf' SIZE 6 M AUTOEXTEND OFF
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8 K
SEGMENT SPACE MANAGEMENT AUTO
Flashback on;

Create table t1 tablespace sugar as select rownum id, lpad ('A', 32, 'A') name from dual connect by level <= 1e5;
Alter system checkpoint;

RMAN> configure channel 1 device type disk rate 128 K;
Using target database control file instead of recovery catalog
New RMAN configuration parameters:
Configure channel 1 device type disk rate 128 K;
New RMAN configuration parameters are successfully stored
-- // Mainly aims to slow down the backup speed.

2. Test 1:
-- // Test script:
$ Cat t1.sh
#! /Bin/bash
Rman target/<EOF>/tmp/t1.txt &
Backup as copy datafile 7 format'/home/oracle/backup/% B _1 ';
# Backup datafile 7 format'/home/oracle/backup/sugar01.dbf _ 1 _ % U ';
Quit
EOF
Echo "sleep $1"
Sleep $1
Sqlplus-s scott/book <EOF
Set numw 12
Update t1 set name = lpad ('B', 32, 'B') where mod (id, 2) = 1;
Commit;
Alter system checkpoint;
Alter system checkpoint;
Alter system checkpoint;
Alter system checkpoint;
Select dbms_flashback.get_system_change_number, sysdate from dual;
Host strings/mnt/ramdisk/book/sugar01.dbf | grep "BBBB" | wc
EOF

$. T1.sh 6
Sleep 6
50000 rows updated.
Commit complete.
System altered.
System altered.
System altered.
System altered.

GET_SYSTEM_CHANGE_NUMBER SYSDATE
-------------------------------------------
13280180133 16:37:08
50000 84680 1811356

SCOTT @ book> select rowid, ora_rowscn from t1 where rownum = 1;
ROWID ORA_ROWSCN
------------------------------
AAAWM5AAHAAAACDAAA 13280180120

SCOTT @ book> select file #, CHECKPOINT_CHANGE #, ABSOLUTE_FUZZY_CHANGE # from v $ datafile_copy order by 2;
FILE # CHECKPOINT_CHANGE # ABSOLUTE_FUZZY_CHANGE #
---------------------------------------------
7 13280180084 0

RMAN> list copy of database;

Using target database control file instead of recovery catalog
List of Datafile Copies
======================================

Key File S Completion Time Ckp SCN Ckp Time
------------------------------------------------------------
76 7 A 16:37:54 13280180084 16:37:06
Name:/home/oracle/backup/sugar01.dbf _ 1
Tag: TAG20171129T163706

$ Strings sugar01.dbf _ 1 | grep "AAAA" | wc
100000 170040 3624077
$ Strings sugar01.dbf _ 1 | grep "BBBB" | wc
0 0 0

-- // The file header scn = 13280180084 starts the backup. After 6 seconds, I modified some data (submitted scn = 13280180120) and did not read the corresponding table T1 at this time.
-- // Why is no BBBB information written to the backup image? I did not understand what I was doing at the time ..........

3. the following content is found in the electronic document <Oracle RMAN 11g Backup and Recovery.pdf>:

-- // Link: http://blog.itpub.net/267265/viewspace-2147878/

Author: Robert G. Freeman Matthew Hart
Page: 689
Press: Mc graw hill
Publication No.: ISBN: 978-0-07-162861-7
MHID: 0 to 07-162861-4

RMAN in Memory P80

RMAN builds buffers in memory through which it streams data blocks for potential backup. This
Memory utilization counts against the total size of the PGA and, sometimes, the SGA. There are
Two kinds of memory buffers. Input buffers are the buffers that are filled with data blocks read
From files that are being backed up. Output buffers are the buffers that are filled when
Memory-to-memory write occurs to determine whether a particle block needs to be backed up.
When the output buffer is filled, it is written to the backup location. The memory buffers differ
Depending on whether you are backing up to or restoring from disk or tape. Figure 2-3 between strates
Input and output buffer allocation. It uses strates a backup of two datafiles being multiplexed
A single backup set.

Input Memory Buffers
When you are backing up the database, the size and number of input memory buffers depend on
The exact backup command being executed. Primarily, they depend on the number of files being
Multiplexed into a single backup. Multiplexing refers to the number of files that will have their
Blocks backed up to the same backup piece. To keep the memory allocation within reason,
Following rules are applied to the memory buffer sizes based on the number of files being backed
Up together:

■ If the number of files going into the backup set is four or less, then RMAN allocates four
Buffers per file at 1 MB per buffer. The total will be 16 MB or less.
...

-- // Read the document carefully. For backing up a data file, follow the instructions and import the data block to PGA first (I feel that the input buffer is entered here ), put "processing" into output buffer,
-- // If the output buffer is full, write it to the corresponding location of the backup file.

-- // In other words, if the data block has been read into PGA, even if DML occurs in the corresponding data block, oracle will not re-read the data file. Only in this way can the data file backed up earlier
-- // The position of. 4 M can be excluded (because I set the data file size to 6 M), so that the remaining position should start at 16 M.

CREATE TABLESPACE SUGAR DATAFILE
'/Mnt/ramdisk/book/sugar01.dbf' SIZE 21 M AUTOEXTEND OFF
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
BLOCKSIZE 8 K
SEGMENT SPACE MANAGEMENT AUTO
Flashback on;

Create table t1 tablespace sugar as select rownum id, lpad ('A', 32, 'A') name from dual connect by level <= 4e5;

SCOTT @ book> select sum (bytes) from dba_extents where segment_name = 't1 ';
SUM (BYTES)
----------
19922944

-- // 19922944/1024/1024 = 19 M.

$. T1.sh 6
Sleep 6
200000 rows updated.
Commit complete.
System altered.
System altered.
System altered.
System altered.
GET_SYSTEM_CHANGE_NUMBER SYSDATE
-------------------------------------------
13280219948 10:49:13

200000 339280 7260120

-- // After the backup is completed:
Starting backup at 2017-11-30 10:49:08
Using target database control file instead of recovery catalog
Allocated channel: ORA_DISK_1
Channel ORA_DISK_1: SID = 94 device type = DISK
Channel ORA_DISK_1: starting datafile copy
Input datafile file number = 00007 name =/mnt/ramdisk/book/sugar01.dbf
Output file name =/home/oracle/backup/sugar01.dbf _ 1 tag = tag20171130t0000908 RECID = 85 STAMP = 961411917
Channel ORA_DISK_1: datafile copy complete, elapsed time: 00:02:55
Channel ORA_DISK_1: throttle time: 0:02:48
Finished backup at 2017-11-30 10:52:04
Starting Control File and SPFILE Autobackup at 10:52:04
Piece handle =/u01/app/oracle/fast_recovery_area/BOOK/autobackup/pai_11_30/o1_mf_s_961411924_f1ywln5x _. bkp comment = NONE
Finished Control File and SPFILE Autobackup at 10:52:05

SCOTT @ book> column name format a50
SCOTT @ book> select recid, file #, NAME, CHECKPOINT_CHANGE #, ABSOLUTE_FUZZY_CHANGE # from v $ datafile_copy where recid = 85;
Recid file # NAME CHECKPOINT_CHANGE # ABSOLUTE_FUZZY_CHANGE #
------------------------------------------------------------------------------------------------------------------
85 7/home/oracle/backup/sugar01.dbf _ 1 13280219895 13280219934
-- // The maximum chunks scn = 13280219934. The BBBB information should be backed up.

SCOTT @ book> select rowid, ora_rowscn from t1 where rownum = 1;
ROWID ORA_ROWSCN
------------------------------
AAAWNaAAHAAAACDAAA 13280219933

$ Strings-t d sugar01.dbf _ 1 | grep "AAAAA" | wc
358205 968151 16037238
$ Strings-t d sugar01.dbf _ 1 | grep "BBBBBB" | wc
41795 113154 1909462

-- // Haha, it finally appears. Now verify whether BBBBB is first available at 16 MB of the data file.

$ Strings-t d sugar01.dbf _ 1 | grep "BBBBBB" | head
16794947 BN bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795029 BL bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795111 BJ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795193 BH bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795275 BF bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795357 BD bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795439 BB bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795521 B @ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795603 B> bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
16795685 B <bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,

-- // 16794947/8192 = 2050.1644287109375, at the block 2050 position. It appears at the offset of 0.1644287109375*8192 = 1347.

SCOTT @ book> select 2050*8192/1024/1024 from dual;
2050*8192/1024/1024
-------------------
16.015625

-- // It is about 16 Mb.
-- // 0.015625*1024*1024 = 16384. the difference is two (the size of the data block is 8192). I guess the OS header and the file header are read (but it does not enter the input buffer) because it is constructed,
-- // Note: If the backup set is backed up, the OS header backup cannot be found, and the file header is actually written to the backup file.
-- // Basically at the 16 m position. Verify that my judgment is correct.

BBED> x/rnc filename "/home/oracle/backup/sugar01.dbf _ 1" block 2050 * kdbr [166]
Rowdata [41] @ 1342
-----------
Flag @ 1342: 0x2c (KDRHFL, KDRHFF, KDRHFH)
Lock @ 1343: 0x02
Cols @ 1344: 2

Col 0 [4] @ 1345: 316577
Col 1 [32] @ 1350: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
-- // The offset is 1350. If you note that there are 3 Characters in front of the strings output, you can check the progress.
-- // By the way: Define the length of the field name 32, so that the length indicator corresponds to the ascii space.

-- // Feel that a single data file backup will use 16 MB of memory as the input buffer. Only in this way can the previous test be parsed.

SCOTT @ book> select count (*) from t1 where DBMS_ROWID.ROWID_BLOCK_NUMBER (rowid) >=2050 and name = LPAD ('B', 32, 'B ');
COUNT (*)
------------
41795

-- // It is also consistent with the result of querying the backup image.
$ Strings-t d sugar01.dbf _ 1 | grep "BBBBBB" | wc
41795 113154 1909462

-- // Finally solve your confusion... I will not perform such tests in the future. I am tired ..
-- // Feel that there is a problem with the tool selection in the test method. For example, the test of writing the file header to the backup image is actually better as long as the strace trace is used.