שחזור טבלה באמצעות RMAN - ilDBA Portal

שחזור טבלה באמצעות RMAN

06/10/2015 | פורסם על ידי

בפוסט זה אציג פיצ'ר שאורקל הוסיפו בגרסת  12c (12.1.0.1 ליתר דיוק) – שחזור טבלה\טבלאות לנקודת זמן מסוימת באמצעות RMAN.

הפיצ'ר יכול להיות שימושי במקרים הבאים:

  • נמחק או השתנה המידע בטבלה ולא ניתן להשתמש ב Flashback Query או Flashback Table לצורך שחזור מכיוון שהמידע הרלוונטי ב Undo Tablespace כבר נמחק
  • רצה פקודת TRUNCATE TABLE על הטבלה, ולכן לא ניתן להשתמש ב Flashback Table או Flashback Query
  • הטבלה נמחקה באמצעות פקודת DROP TABLE, אך לא ניתן לשחזר באמצעות Flashback Drop כי האובייקט כבר לא קיים ב Recycle Bin בגלל Space Pressure ב Tablespace, או לחילופין במקרה שבוצעה פקודת Purge לטבלה
  • בוצעה פקודת DDL ששינתה את מבנה הטבלה ולכן לא ניתן לשחזר את הטבלה באמצעות Flashback Table ללפני פעולת ה DDL

מה שניתן היה לבצע לפני גרסת  12 זה לשחזר את כל ה Database לנקודת זמן בה המידע בטבלה או בטבלאות היה תקין, כלומר, לפני שבוצעה הפעולה ה"הרסנית". הבעיה בפתרון הזה היא שגם כל שאר המידע ישוחזר לאותו נקודת זמן – כלומר, יהיה איבוד מידע .

אופציה טובה יותר היא לבצע שחזור לנקודת זמן של Tablespace (Tablespace point in-time recovery) ל auxiliary instance ולאחר-מכן לבצע Export ו Import של הטבלאות.

הפיצ'ר החדש למעשה חוסך עבודה וזמן בכך שהוא מבצע את כל התהליך הבא בצורה אוטומטית:

  • מייצר Auxiliary Instance
  • משחזר את ה Tablespaces הרלוונטיים לנקודת הזמן שבחרנו (כמובן שחובה שיהיה גיבוי זמין)
  • מגבה את הטבלה לקובץ באמצעות Data Pump Export
  • משחזר את הטבלה באמצעות Data Pump Import

הדגמה:

  1. בשלב הראשון נייצר טבלה ונכניס לה רשומה
SQL> create table emp (id number, name varchar2(20));
Table created.

SQL> insert into emp values (1, 'DAVID');
1 row created.

SQL> commit;
Commit complete.
  1. כעת נבדוק מה ה SCN הנוכחי כדי שנשתמש בו לאחר-מכן בעת השחזור.

הערה: ניתן לשחזר עם RMAN לנקודת זמן מסוימת באמצעות SCN, TIME, או Log Sequence#.

SQL> select current_scn from v$database;
CURRENT_SCN
-----------
25427549

  1. נריץ פקודת DROP עם PURGE:
SQL> drop table emp purge;
Table dropped.
  1. כעת, כל מה שנותר לבצע הוא להתחבר עם RMAN ולהריץ את פקודת ה RECOVER TABLE, לציין את ה SCN שאליו אנו רוצים לשחזר וגם auxiliary destination שזה הנתיב בו RMAN  יכתוב את כל הקבצים של ה Auxiliary instance וגם את קובץ ה Data Pump:
RMAN> recover table pini.emp until scn 25427549 auxiliary destination '/oravl01/recover';

Starting recover at 07-SEP-15
using channel ORA_DISK_1
RMAN-05026: WARNING: presuming following set of tablespaces applies to specified Point-in-Time

List of tablespaces expected to have UNDO segments
Tablespace SYSTEM
Tablespace UNDOTBS1

Creating automatic instance, with SID='Fkyk'

initialization parameters used for automatic instance:
db_name=O12102NP
db_unique_name=Fkyk_pitr_O12102NP
compatible=12.1.0.2.0
db_block_size=8192
db_files=200
diagnostic_dest=/oravl01/oracle
_system_trig_enabled=FALSE
sga_target=1024M
processes=200
db_create_file_dest=/oravl01/recover
log_archive_dest_1='location=/oravl01/recover'
#No auxiliary parameter file used
...
...
...
...
Performing import of tables...
   IMPDP> Master table "SYS"."TSPITR_IMP_Fkyk_kvas" successfully loaded/unloaded
   IMPDP> Starting "SYS"."TSPITR_IMP_Fkyk_kvas":
   IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE
   IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
   IMPDP> . . imported "PINI"."EMP"                                5.476 KB       1 rows
   IMPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
   IMPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
   IMPDP> Job "SYS"."TSPITR_IMP_Fkyk_kvas" successfully completed at Mon Sep 7 14:13:05 2015 elapsed 0 00:00:11
Import completed

Removing automatic instance
Automatic instance removed
auxiliary instance file /oravl01/recover/O12102NP/datafile/o1_mf_temp_bytw2co8_.tmp deleted
auxiliary instance file /oravl01/recover/FKYK_PITR_O12102NP/onlinelog/o1_mf_3_bytw4md4_.log deleted
auxiliary instance file /oravl01/recover/FKYK_PITR_O12102NP/onlinelog/o1_mf_2_bytw4m1t_.log deleted
auxiliary instance file /oravl01/recover/FKYK_PITR_O12102NP/onlinelog/o1_mf_1_bytw4lhq_.log deleted
auxiliary instance file /oravl01/recover/FKYK_PITR_O12102NP/datafile/o1_mf_users_bytw4gos_.dbf deleted
auxiliary instance file /oravl01/recover/O12102NP/datafile/o1_mf_sysaux_bytvy598_.dbf deleted
auxiliary instance file /oravl01/recover/O12102NP/datafile/o1_mf_undotbs1_bytvy590_.dbf deleted
auxiliary instance file /oravl01/recover/O12102NP/datafile/o1_mf_system_bytvy59h_.dbf deleted
auxiliary instance file /oravl01/recover/O12102NP/controlfile/o1_mf_bytvxw4w_.ctl deleted
auxiliary instance file tspitr_Fkyk_10996.dmp deleted
Finished recover at 07-SEP-15

ברגע ש RMAN  סיים את עבודתו, יש ב source database את הטבלה עדכנית לנקודת הזמן אליה ביקשנו לשחזר את הטבלה. במקרה שלנו, הטבלה עדכנית לSCN 25427549

מספר הערות לגבי פקודת ה RECOVER TABLE:

  • ניתן לשחזר מספר טבלאות בו-זמנית. פשוט צריך לציין את כל הטבלאות מופרדות בפסיקים
  • ניתן לציין נתיב שונה לקובץ ה Dump File באמצעות הפרמטר DATAPUMP DESTINATION
  • בסוף תהליך השחזור ניתן להגדיר ל RMAN לשחזר את הטבלה עם שם שונה מהשם המקורי שלה באמצעות הפרמטר REMAP TABLE
  • בסוף תהליך השחזור ניתן להגדיר ל RMAN לשחזר את הטבלה ב Tablespace שונה מהמקורי שלה באמצעות הפרמטר REMAP TABLESPACE
  • ניתן לדלג על השלב האחרון של ביצוע השחזור בפועל באמצעות הפרמטר NOTABLEIMPORT ואז RMAN יגבה את הטבלה לקובץ באמצעות Export Data Pump אך לא יריץ את ה IMPORT DATA PUMP
  • הפיצ'ר תומך גם ב Partitions ולא רק בטבלאות

סיכום:

  • שימוש בפיצ'ר זה מאפשר לשחזר טבלה\טבלאות לנקודת זמן בפשטות
  • מכיוון שכחלק מתהליך השחזור RMAN יוצר Auxiliary Instance וגם מבצע Export ו Import, אז כמובן שיש תקורה של משאבים – בעיקר של I/O וכמובן זמן שחזור ארוך יחסית
  • המסקנה: במקרים בהם ניתן לשחזר באמצעות שיטות אחרות,כמו שימוש ב Flashback Table או Flashback Drop ואפילו שחזור מסביבת Standby שהסנכרון בה מושהה ועוד לא הסתנכרנה הפעולה ההרסנית, אז כמובן שזה עדיף כי התקורה מבחינת משאבים תהיה נמוכה יותר וזמן השחזור יהיה מהיר יותר. לעומת זאת, במקרים בהם אין אלטרנטיבה, שימוש בפיצ'ר זה מפשט ומקצר את תהליך שחזור הטבלה.


נתראה בפוסט הבא!

ניתן ליצור איתי קשר באמצעות המייל: pini.dibask@software.dell.com

הבלוג שלי: OracleDBPro.Blogspot.c om

The following two tabs change content below.
פיני דיבסק (pini.dibask@software.dell.com) הוא Oracle DBA בכיר עם 10 שנות ניסיון, ובעל הסמכה בינלאומית של Oracle Certified Professional. את הקריירה החל בחיל המודיעין כמומחה תשתיות וביצועים והשתחרר בדרגת סרן כראש צוות DBA. כיום הוא Oracle Domain Expert בחברת Dell Software. בעל בלוג מקצועי: http://oracledbpro.blogspot.com וחבר פעיל בקהילת ה OTN. פיני בוגר תואר ראשון בניהול ומדעי המחשב של האוניברסיטה הפתוחה.

השאר תגובה:

שם (חובה):
אימייל (לא יפורסם) (חובה):
תגובה (חובה):

*



מאמרים קשורים

PL/SQL

PL/SQL Injection – The Beginning

עודד רז פותח בסדרת מאמרים על Pl/sql [...]

תיעוד בסיס הנתונים – למה זה טוב?

ישנם מספר נושאים חשובים שיש לתת עליהם את הדעת בפיתוח ותכנון בסיס נתונים. כמובן שצריך לשים לב לנירמול נכון של הטבלאות, וכמובן שצריך להגדיר סטנדרט לכתיבה נכונה של הקוד, וכמובן שאי אפשר בלי [...]

צבעים דינמיים ב-SSRS

כאשר לקוח שלי ולא משנה אם הוא מבוסס אורקל או SQL Server חושב על פתרון Reporting אני ישר מציע לו את ה- Sql Server Reporting Services. שתי סיבות עיקריות להצעה שלי: רישוי ויכולות. איתי בנימין מסביר על צבעים דינמים [...]

Oracle Text For Dummies – חלק א

כולכם בוודאי שמעתם את המושג "אורקל טקסט" או "טקסט אינדקס" בהקשר זה או אחר. אם אתם רוצים להכיר עוד קצת (ממש על קצה המזלג) את הפיצ'ר המגניב והמאוד שימושי הזה שבאמת שווה להכיר- הגעתם למקום הנכון! [...]
Copyright 2017 ilDBA Portal. Brought to you by Brillix - Israel Leading DBA company. Sponsored by: DBSnaps - Database Video Tutorialss
Website Security Test
%d בלוגרים אהבו את זה: