Một hóa thân mồ côi là gì?


9

Hóa thân được giải thích trong một câu trả lời cho một câu hỏi khác trên trang web này. Câu trả lời đề cập đến những hiện thân 'mồ côi':

Có một số yếu tố khác dẫn đến việc hóa thân ORPHANED và sao lưu OBSOLLEX

Tôi thấy từ các tài liệu OracleV$DATABASE_INCARNATIONbao gồm một STATUScột có thể có giá trị ORPHAN, CURRENThoặc PARENT, mà phải liên quan.

Hóa thân 'mồ côi' là gì và những bước nào sẽ dẫn đến một hàng với STATUS= ORPHANin V$DATABASE_INCARNATION?

Câu trả lời:


8

Sau đây là một hình ảnh ngắn mà tôi sẽ sử dụng để giải thích khi trẻ mồ côi được tạo ra trong các cơ sở dữ liệu. Đó là một biến thể của đồ họa mà tôi đã sử dụng để giải thích các hóa thân trong câu trả lời của mình cho câu hỏi Có ai có thể giải thích cho tôi khái niệm về hóa thân thành cơ sở dữ liệu trong cơ sở dữ liệu của Oracle theo cách dễ hiểu không?

Tôi hy vọng bạn tận hưởng cuộc hành trình.

                                          restore db    +-----+     +-----+     +-----+          
                                          recover db    | 2>3 | --> |  3  | --> |  3  | -->  ... 
                                          resetlogs     +-----+     +-----+     +-----+  ^       
                                                            ^ Incarn   3           3     |    3  
                                                           /  SCN #   500         600    |   700 
                                                          /                              |          
                                                         /                               |          
             restore db    +-----+          +-----+     +-----+                          |          
             recover db    | 1>2 | -------> |  2  | --> |  2  | -->  ...                 |          
             resetlogs     +-----+          +-----+     +-----+  ^                       |          
                           ^       Incarn.     2 \         2     |    2                  |          
                          /        SCN #      300 \       400    |   500                 |          
                         /                         \             |                       |          
                        /                           + --------------------+              |          
        +-----+     +-----+     +-----+                          |         \    +-----+  |  +-----+ 
    --> |  1  | --> |  1  | --> |  1  | -->   ...                |          +-> | 2>4 | --> |  4  | 
        +-----+     +-----+     +-----+  ^                       |   restore db +-----+  |  +-----+ 
Incarn.    1           1           1     |     1           2     |   recover db          |     4    
SCN #     100         200         300    |    400         400    |   resetlogs           |    400   
                                         |                       |                       |          
Backup   11:00 ----- 12:00 ----- 13:00 ----- 14:00 ----- 15:00 ----- 16:00 ----- 17:00 ----- 18:00  
                                         |                       |                       |          
Restore/                                (1)                     (2)                     (3)         
Recovery                                                                                            

Khôi phục cơ sở dữ liệu đến thời điểm (1)

Ở đâu đó một chút sau 13:00 (1 giờ chiều) ai đó quyết định rằng cơ sở dữ liệu phải được khôi phục đến 12:00 (12 giờ trưa). DBA sẽ đặt ra một loạt các lệnh RMAN để khôi phục cơ sở dữ liệu về thời điểm đó hoặc nhấp vào thông qua GUI tuyệt vời để bắt đầu khôi phục / khôi phục từ nhà cung cấp bên thứ 3.

RMAN lấy bản sao lưu FULL của cơ sở dữ liệu và tất cả các bản sao lưu Nhật ký lưu trữ từ đĩa / băng và khôi phục chúng vào đĩa. Trong giai đoạn phục hồi, RMAN sẽ kiểm tra xem tất cả thông tin có liên quan có sẵn không và chuyển tiếp tất cả các giao dịch đã hoàn thành đến Điểm kịp thời và khôi phục tất cả các giao dịch chưa hoàn thành về Điểm trong thời gian, để đảm bảo cơ sở dữ liệu ở trạng thái nhất quán.

Trước khi cơ sở dữ liệu có thể được mở cho công chúng, cơ sở dữ liệu phải đảm bảo rằng tất cả các bản sao lưu trong tương lai không xung đột với các bản sao lưu trước đó. Đây là khi một hóa thân mới sẽ được tạo và nó xảy ra khi bạn thực hiện lệnh sau để mở cơ sở dữ liệu:

ALTER DATABASE OPEN RESETLOGS;

Bạn có thể chạy tập lệnh sau đối với phiên bản của bạn để truy xuất chế độ xem phân cấp của các hóa thân (hiện tại) của bạn:

set pages 50               --- repeat header every 50 records
set lines 230              --- set lines(ize) length to 230
column path format a40     --- set column path to alpha-numeric 40
alter sessiosn set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
                           --- set date format of date columns to something more detailed
select 
    INCARNATION#, 
    PRIOR_INCARNATION#, 
    RESETLOGS_CHANGE#, 
    RESETLOGS_TIME, 
    STATUS, 
    SYS_CONNECT_BY_PATH(INCARNATION#, ' -> ') Path 
    FROM v$database_incarnation 
    WHERE LEVEL >=1 START WITH INCARNATION# = '1' 
        CONNECT BY PRIOR INCARNATION# = PRIOR_INCARNATION# 
    ORDER BY LEVEL, Path, RESETLOGS_TIME;

Hóa thân hiện tại của cơ sở dữ liệu sẽ tương tự như sau:

INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME      STATUS  PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
           1                  0                 1 2017-03-08 15:57:31 PARENT   -> 1
           2                  1               200 2018-07-27 13:20:00 CURRENT  -> 1 -> 2

Sử dụng đồ họa, chúng ta có thể thấy rằng chúng ta đã chuyển từ đường dẫn chứa hóa thân 1 sang đường dẫn với hóa thân 2, bởi vì chúng ta đã mở cơ sở dữ liệu RESETLOGSvà cơ sở dữ liệu đã tạo ra một hóa thân mới.

Khôi phục cơ sở dữ liệu đến thời điểm (2)

Một lần nữa, giả sử cơ sở dữ liệu tiếp tục chạy sau hành động khôi phục / khôi phục đầu tiên và sau 15:00 (3 giờ chiều), ai đó quyết định cần phải khôi phục / khôi phục mới trở lại toàn bộ lúc 15:00 (3 giờ chiều) cùng ngày.

RMAN sẽ khôi phục các tệp, khôi phục cơ sở dữ liệu và đặt ra ALTER DATABASE OPEN RESETLOGSđể đưa cơ sở dữ liệu trở lại trực tuyến. Số INCARNATION # sẽ được đặt thành 3 và bản sao lưu đầu tiên lúc 16:00 sẽ chứa thông tin:

INCARNATION#    3
SCN#           500
Time......... 16:00

Nếu chúng ta truy vấn các hóa thân trong cơ sở dữ liệu bằng cách sử dụng đoạn mã trên, chúng ta sẽ nhận được một cái gì đó như thế này:

INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME      STATUS  PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
           1                  0                 1 2017-03-08 15:57:31 PARENT   -> 1
           2                  1               200 2018-07-27 13:20:00 PARENT   -> 1 -> 2
           3                  2               400 2018-07-27 15:20:00 CURRENT  -> 1 -> 2 -> 3

Khôi phục cơ sở dữ liệu đến thời điểm (3)

Một lần nữa giả sử cơ sở dữ liệu tiếp tục chạy sau hành động khôi phục / khôi phục thứ hai và một chút sau 17:00 (5 giờ chiều) ai đó quyết định cần phải khôi phục / khôi phục mới trở lại 14:00 (2 giờ chiều) cùng ngày.

RMAN sẽ khôi phục các tệp, khôi phục cơ sở dữ liệu và đặt ra ALTER DATABASE OPEN RESETLOGSđể đưa cơ sở dữ liệu trở lại trực tuyến. Số INCARNATION # sẽ được đặt thành 4 và bản sao lưu đầu tiên lúc 18:00 sẽ chứa thông tin:

INCARNATION#    4
SCN#           400
Time......... 18:00

Nếu chúng ta truy vấn các hóa thân trong cơ sở dữ liệu bằng cách sử dụng đoạn mã trên, chúng ta sẽ nhận được một cái gì đó như thế này:

INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME      STATUS  PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
           1                  0                 1 2017-03-08 15:57:31 PARENT   -> 1
           2                  1               200 2018-07-16 13:20:00 PARENT   -> 1 -> 2
           3                  2               400 2018-07-17 15:20:00 ORPHAN   -> 1 -> 2 -> 3
           4                  2               300 2018-07-17 17:20:00 CURRENT  -> 1 -> 2 -> 4

Chuyện gì xảy ra vậy? Chúng tôi có một đứa trẻ mồ côi!

Hóa thân mồ côi ...

Nếu bạn nhìn vào đồ họa, chúng tôi hiện đang đứng trên quảng trường vào lúc 18:00 (6 giờ tối) với Incarnation 4 và SCN 400. Bây giờ nếu bạn theo dòng đó trở lại từ đầu, bạn có thể thấy rằng chúng ta sẽ đi từ hóa thân 4 sao lưu để hóa thân 2 và sau đó quay lại hóa thân 1, đó là khi cơ sở dữ liệu được tạo.

Điều này cũng tương ứng với đầu ra (đơn giản hóa) các tập lệnh của tôi.

INCARNATION# PRIOR_INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME      STATUS  PATH
------------ ------------------ ----------------- ------------------- ------- --------------------
           4                  2               300 2018-07-17 17:20:00 CURRENT  -> 1 -> 2 -> 4

Vậy chuyện gì đã xảy ra với hóa thân 3? Là hóa thân 3 xấu hay cũ hay những gì cho?

Câu trả lời

Không, hóa thân 3 không tệ, nó chỉ mồ côi.

Ở quy mô lớn hơn với nhiều thời gian hơn giữa các bản sao lưu và khôi phục, bạn vẫn có thể khôi phục / khôi phục cơ sở dữ liệu đến một thời điểm trong dòng dõi hóa thân 3. Bạn sẽ đặt ra lệnh sau:

RESET DATABASE TO INCARNATION 3;

... và sau đó khôi phục / khôi phục cơ sở dữ liệu đến thời điểm đó giống như bạn sẽ khôi phục / khôi phục cơ sở dữ liệu khác.

Điều mà ORPHANtrạng thái nói với bạn, đó là hóa thân 3 không còn liên quan đến trạng thái hiện tại của cơ sở dữ liệu với hiện thân hiện tại 4. Hiện thân mồ côi 3 không còn cần thiết để khôi phục / khôi phục cơ sở dữ liệu theo dòng thời gian hiện tại.

... Kết quả trong Sao lưu lỗi thời

Bây giờ nhìn vào các bản sao lưu cơ sở dữ liệu liên quan đến hóa thân mồ côi, RMAN cũng xác định rằng các bản sao lưu của cô gái mồ côi là OBSOLETE. Nhưng đó là một câu chuyện cho một câu hỏi và trả lời khác ...


7

RC_DATABASE_INCARNATION

ORPHAN nếu đây là một hóa thân không hiện tại không phải là tổ tiên trực tiếp của hóa thân hiện tại.

Các bước để tái sản xuất:

SQL> select incarnation#, status from v$database_incarnation;

INCARNATION# STATUS
------------ -------
           1 PARENT
           2 CURRENT

SQL> select current_scn from v$database;

CURRENT_SCN
-----------
    3393014

SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 1073741824 bytes
Fixed Size                  8628936 bytes
Variable Size             394265912 bytes
Database Buffers          662700032 bytes
Redo Buffers                8146944 bytes
Database mounted.
SQL> flashback database to scn 3393014;

Flashback complete.

SQL> alter database open resetlogs;

Database altered.

SQL> select incarnation#, status from v$database_incarnation;

INCARNATION# STATUS
------------ -------
           1 PARENT
           2 PARENT
           3 CURRENT

SQL> select current_scn from v$database;

CURRENT_SCN
-----------
    3393975

SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 1073741824 bytes
Fixed Size                  8628936 bytes
Variable Size             394265912 bytes
Database Buffers          662700032 bytes
Redo Buffers                8146944 bytes
Database mounted.
SQL> flashback database to scn 3393200;

Flashback complete.

SQL> alter database open resetlogs;

Database altered.

SQL> select incarnation#, status from v$database_incarnation;

INCARNATION# STATUS
------------ -------
           1 PARENT
           2 PARENT
           3 PARENT
           4 CURRENT

SQL> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 1073741824 bytes
Fixed Size                  8628936 bytes
Variable Size             394265912 bytes
Database Buffers          662700032 bytes
Redo Buffers                8146944 bytes
Database mounted.
SQL> flashback database to scn 3393014;

Flashback complete.

SQL> alter database open resetlogs;

Database altered.

SQL> select incarnation#, status from v$database_incarnation;

INCARNATION# STATUS
------------ -------
           1 PARENT
           2 PARENT
           3 ORPHAN
           4 ORPHAN
           5 CURRENT
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.