בעזרת Datastream אתם יכולים להעביר בסטרימינג נתונים היסטוריים ושינויים שוטפים ממסד נתונים של Oracle אל היעד, כדי לבצע ניתוח בזמן אמת ולסנכרן את מסד הנתונים.
לפני שמגדירים מקור Oracle, כדאי לעיין בהתנהגות השכפול, בגרסאות ובסוגי מסדי הנתונים הנתמכים, בהגדרת מסד הנתונים, בשיטות המומלצות ובמגבלות הידועות ב-Datastream.
התנהגות
ב-Datastream יש שתי שיטות לחילוץ שינויים בנתונים מקובצי יומן Redo אונליין: קורא היומן הבינארי של Oracle (גרסת טרום-השקה (Preview)) ו-Oracle LogMiner.
בשיטה של קורא היומן הבינארי (גרסת טרום-השקה (Preview)), מתרחשת ההתנהגות הבאה:
אם יש השהיית קריאה בזמן חילוץ השינויים מקובצי היומן אונליין, Datastream מחלץ את השינויים מקובצי יומן שהועברו לארכיון.
Datastream משכפל רק שינויים שבוצעו ביעד. טרנזקציות שלא בוצעו או שבוטלו לא משוכפלות.
קורא הבינארי תומך בשכפול עמודות Oracle
VARCHAR2באורך של יותר מ-4,000 תווים.
בנוסף, Datastream תומך בתכונה Oracle LogMiner כדי לחשוף שינויים בנתונים. השיטה פועלת באופן הבא:
- אפשר לבחור את כל הסכימות או סכימות ספציפיות ממסד נתונים נתון, וגם את כל הטבלאות מהסכימות או טבלאות ספציפיות.
- כל הנתונים ההיסטוריים משוכפלים.
- כל השינויים בשפת הטיפול בנתונים (DML), כמו הוספות, עדכונים ומחיקות ממסדי הנתונים ומהטבלאות שצוינו, משוכפלים.
- Datastream משכפל ליעד גם שינויים שבוצעו וגם שינויים שלא בוצעו, במקרים מסוימים. Datastream קורא שינויים שלא בוצעו. במקרה של החזרה למצב קודם, רשומות הפלט של Datastream כוללות גם את הפעולה ההפוכה. לדוגמה, אם יש פעולת
INSERTשבוטלה, רשומות הפלט יכילו גם פעולתDELETEתואמת. במקרה כזה, האירוע יופיע כאירועDELETEעםROWIDבלבד.
מילוי חוסרים (backfill) מבוסס-ROWID
ב-Oracle, ROWID היא עמודה מדומה שבה מאוחסנים מזהים ייחודיים של שורות בטבלה. Datastream משתמש בערכים של ROWID לפעולות המילוי החוזר (backfill). לכן, מומלץ לא לבצע פעולות שיכולות לשנות את הערכים של ROWID במסד הנתונים של Oracle במקור עד להשלמת פעולת המילוי החוזר.
הפעולות שיכולות לשנות את הערכים של ROWID כוללות:
העברה פיזית של שורות:
- פעולות ייצוא וייבוא: כשמייצאים טבלה ואז מייבאים אותה בחזרה, המיקום הפיזי של השורות עשוי להשתנות, וכתוצאה מכך יתקבלו ערכי
ROWIDחדשים. - פקודת
ALTER TABLE (...) MOVE: העברת טבלה למרחב טבלאות אחר יכולה לשנות את האחסון הפיזי ולהוביל לשינויים ב-ROWID. - הפקודה
ALTER TABLE (...) SHRINK SPACE: הפקודה הזו דוחסת את הטבלה, מה שעלול להזיז שורות ולהשפיע על הערכים שלROWID. - פעולות חלוקה למחיצות: פיצול, מיזוג או העברה של מחיצות יכולים לשנות את המיקום הפיזי של השורות ואת ערכי ה-
ROWIDשלהן.
- פעולות ייצוא וייבוא: כשמייצאים טבלה ואז מייבאים אותה בחזרה, המיקום הפיזי של השורות עשוי להשתנות, וכתוצאה מכך יתקבלו ערכי
פעולות Flashback:
- הפקודה
FLASHBACK TABLE: שחזור טבלה למצב קודם כולל מחיקה והוספה מחדש של שורות, וכך נוצרים ערכיROWIDחדשים. -
FLASHBACK_TRANSACTION_QUERY: כמוFLASHBACK TABLE. ביטול של טרנזקציה יכול לגרום ל-ROWIDשינויים אם שורות נמחקו או עודכנו בטרנזקציה.
- הפקודה
פתרון בעיות במילוי חוסרים בטבלת מחיצות ב-Oracle 11.2.0.4
אם המילוי החוזר נכשל בטבלה מחולקת ב-Oracle 11.2.0.4 עם שגיאת אחזור לא צפויה (אינדקס מחוץ לגבולות), זה קורה בגלל באג במטא-נתונים של Oracle שבו שאילתות ל-ALL_OBJECTS לא מחזירות מחיצות משנה.
- פתרון עקיף: מבטלים באופן זמני את ההרשאה
SELECT ON DBA_EXTENTSשל המשתמש ב-Datastream (לדוגמה,REVOKE SELECT ON sys.dba_extents FROM USER_NAME;). כך Datastream נאלץ להשתמש במילוי חוסרים שמבוסס על אינדקס, ועוקף את הבעיה במטא-נתונים.
מסדי נתונים במצב המתנה
כשמשתמשים במסד נתונים בגיבוי חם של Oracle Active Data Guard כמקור, Datastream קורא את יומני ה-Redo שהועברו לארכיון. כדי לוודא ש-Datastream מעבד רק יומני Redo שהוחלו בהצלחה על מסד הנתונים במצב המתנה, צריך לסנן תצוגות Oracle רגילות, כמו V$ARCHIVED_LOG ו-GV$ARCHIVED_LOG, כך שיכללו רק רשומות עם המסנן APPLIED = 'YES'.
כדי לעשות את זה, אתם יכולים ליצור תצוגות בהתאמה אישית. חשוב לוודא שאתם נותנים למשתמש ב-Datastream את הרשאת הגישה המתאימה לתצוגות האלה. לדוגמה:
CREATE OR REPLACE VIEW USER_NAME.local_v$archived_log AS
SELECT * FROM sys.v_$ARCHIVED_LOG
WHERE RESETLOGS_CHANGE# = (SELECT resetlogs_change# FROM v$database)
AND APPLIED = 'YES';
CREATE OR REPLACE VIEW USER_NAME.local_gv$archived_log AS
SELECT * FROM sys.gv_$ARCHIVED_LOG
WHERE RESETLOGS_CHANGE# = (SELECT resetlogs_change# FROM v$database)
AND APPLIED = 'YES';
CREATE SYNONYM USER_NAME.v$archived_log FOR USER_NAME.local_v$archived_log;
CREATE SYNONYM USER_NAME.gv$archived_log FOR USER_NAME.local_gv$archived_log;
לשימוש במסנן APPLIED = 'YES' יש השפעה על עדכניות הנתונים.
Datastream ממתין עד שתהליך השחזור המנוהל (MRP) של מסד הנתונים במצב המתנה יחיל את היומנים ויעדכן את העמודה APPLIED לערך YES, ורק אז הוא מחלץ את השינויים. אם תהליך ה-MRP מתעכב או מושהה, למשל אם אתם משעים את תהליך ההחלה של המתנה, זה משפיע ישירות על עדכניות הנתונים המשוכפלים. Datastream נכנס ללולאת ניסיון חוזר ומעכב את העיבוד עד שיומני הארכיון החדשים שהוחלו יהיו זמינים.
ההגדרה הזו רלוונטית מאוד כשמשכפלים טבלאות שכוללות עמודות של אובייקטים גדולים (LOB). בפעולות UPDATE, הערכים המפורטים של עמודות LOB לא מופיעים ביומני ה-Redo, ולכן Datastream צריך לשלוח שאילתה למסד הנתונים כדי לאחזר את השורה המשויכת. אם Datastream מעבד יומן Redo שלא הוחל ומנסה לאחזר את ערך ה-LOB ממסד הנתונים במצב המתנה, יכול להיות שהוא יאחזר ערך שגוי ומיושן. כדי להבטיח שהנתונים הנכונים יאוחזרו, Datastream מסנן את היומנים ומוודא שהם הוחלו במלואם.
גרסאות
Datastream תומך בגרסאות הבאות של מסד הנתונים של Oracle:
- Oracle 11g, גרסה 11.2.0.4 (נתמכת רק בשיטת Logminer CDC)
- Oracle 12c, גרסה 12.1.0.2
- Oracle 12c, גרסה 12.2.0.1
- Oracle 18c
- Oracle 19c
- Oracle 21c
Datastream תומך בסוגים הבאים של מסדי נתונים של Oracle:
- אירוח עצמי בארגון או אצל כל ספק שירותי ענן
- Amazon RDS ל-Oracle
- Oracle Cloud
- Oracle Exadata
- Oracle RAC
- מסד נתונים במצב המתנה של Oracle Active Data Guard
הגדרה
כדי להגדיר מסד נתונים של Oracle כמקור, כך שיהיה אפשר להעביר ממנו נתונים בסטרימינג ליעד, צריך להגדיר את מסד הנתונים כך שתהיה לו גישה, להגדיר רישום ביומן ולהגדיר מדיניות שמירת נתונים.
במאמר הגדרת מסד נתונים של Oracle כמקור מוסבר איך להגדיר את מסד הנתונים הזה כדי ש-Datastream יוכל לשלוף ממנו נתונים ליעד.
שיטות מומלצות
בקטע הזה מתוארות השיטות המומלצות להגדרת מקור Oracle לשימוש עם Datastream.
תלות באותיות רישיות בקורא בינארי
כשמגדירים מקור Oracle באמצעות שיטת ה-CDC של קורא בינארי ומציינים שמות של ספריות ליומני ביצוע מחדש וליומני ארכיון, חשוב לזכור שהשמות תלויי אותיות רישיות. חשוב לוודא ששמות הספריות שאתם מספקים בפרופיל החיבור של Datastream תואמים בדיוק לשמות הספריות במסד הנתונים של Oracle.
בו-זמניות (concurrency) של CDC
כדי לצמצם את העיכוב בשכפול, חשוב לוודא ש-Datastream יכול לעבד את יומני ה-Redo באותה מהירות שבה הם נוצרים במקור ב-Oracle. כשמשתמשים בשיטת CDC של קורא בינארי, בו-זמניות של Datastream היא ברמת קובץ יומן ה-redo: כל משימה שמוגדרת על ידי maxConcurrentCdcTasks מעבדת קובץ אחד בכל פעם.
מומלץ להשתמש במתודולוגיה הבאה:
- כוונון של בו-זמניות ב-Datastream: מזהים את המספר הממוצע של החלפות יומן Redo במהלך שעות הפעילות העמוסות ביותר, ומגדירים את הפרמטר
maxConcurrentCdcTasksבהתאם. מידע נוסף זמין במאמר המספר המקסימלי של משימות CDC. - הגדרת החלפת יומנים ב-Oracle: מגדירים את Oracle כך שיחליף יומנים לעיתים קרובות, למשל כל 10-20 דקות. כך נוצר זרם קבוע של יחידות עבודה קטנות יותר, שמאפשר למשימות בו-זמניות של Datastream לפעול במקביל בצורה יעילה.
מומלץ לבצע אופטימיזציה להגדרות כך שיהיו מספיק משימות בו-זמניות ב-Datastream כדי לטפל ביצירה התכופה של יומני Redo קטנים יותר מ-Oracle. מידע נוסף על בקרת בו-זמניות של שידורים
מגבלות ידועות
המגבלות הידועות בשימוש במסד נתונים של Oracle כמקור כוללות:
- הסטרימינג מוגבל ל-10,000 טבלאות. אם מקור נתונים כולל יותר מ-10,000 טבלאות, יכול להיות שיופיעו שגיאות.
- Datastream תומך בארכיטקטורת ריבוי דיירים של Oracle (CDB/PDB), אבל אפשר לשכפל רק מסד נתונים אחד שניתן לחיבור בסטרים.
- אין תמיכה ב-Oracle Autonomous Database.
- בטבלאות שאין בהן מפתח ראשי, Datastream משתמש ב-
ROWIDשל השורה כדי לבצע פעולת מיזוג בצד הצרכן. חשוב לזכור שהערך שלROWIDלא בהכרח ייחודי. לדוגמה, אם מוחקים שורה ומוסיפים אותה מחדש באמצעות כלי הייצוא/ייבוא של Oracle, יכול להיות שהערך שלROWIDישתנה. אם מוחקים שורה, Oracle יכולה להקצות מחדש את ה-ROWIDשלה לשורה חדשה שנוספה מאוחר יותר. - אין תמיכה בטבלאות מאורגנות לפי אינדקס (IOT).
- אין תמיכה בטבלאות זמניות.
- אין תמיכה בטבלאות אובייקטים, כמו טבלאות אובייקטים בהתאמה אישית או טבלאות
XMLType. - סוגי הנתונים הבאים של Oracle לא נתמכים ולא משוכפלים. עמודות מהסוגים האלה משוכפלות כערכי
NULLביעד:ANYDATA,ANYDATASET,ANYTYPE-
VARRAY(מערכים של Oracle) BFILE,BFILENAMEINTERVAL DAY TO SECOND,INTERVAL YEAR TO MONTHLONG,LONG RAWUROWIDUDT- סוגי מדיה וסוגים מרחביים:
ORDAUDIO,ORDDATASOURCE,ORDDICOM,ORDDOC,ORDIMAGE,ORDVIDEO,SDO_GEOMETRY(וכל שאר הסוגים שלMDSYS.SDO_*).
כדי להעביר בסטרימינג עמודות של סוגי נתונים של אובייקטים גדולים, כמו
XMLTYPE, אובייקטים בינאריים גדולים (BLOB), אובייקטים גדולים של תווים (CLOB) ואובייקטים גדולים של תווים לאומיים (NCLOB), צריך לכלול את הדגלstreamLargeObjectsבהגדרת הסטרימינג. אם לא תכללו את הדגל, Datastream לא יעביר בסטרימינג עמודות כאלה והן יוחלפו בערכיNULLביעד. מידע נוסף זמין במאמר הפעלת סטרימינג של אובייקטים גדולים במקורות של Oracle. כשמעבירים בסטרימינג את סוגי הנתונים האלה, Datastream צריך לשלוח שאילתה למסד הנתונים של המקור כדי לאחזר ערכי LOB חסרים בנקודת זמן מסוימת (בתהליך חיפוש פעיל שנקרא השלמה). זה קורה בתרחישים הבאים:- כשמטענים ייעודיים (payloads) של LOB שלא השתנו נמחקים מיומן ה-Redo במהלך
UPDATE - במהלך פעולות DML שכוללות סוגי XML בינאריים
- במהלך כל ניתוח DML בטבלה שמכילה LOB, אם ה-stream משתמש בשיטת LogMiner
Datastream מעביר את העמודות האלה באמצעות שליחת שאילתות למסד הנתונים, ולכן יכול להיות ששינויי ביניים לא יתועדו בתרחישים שכוללים עדכונים מהירים בזה אחר זה או מחיקה מהירה אחרי הוספה. חשוב לדעת שפעולות
DELETEלא מפעילות את ההשלמה. המגבלה הזו רלוונטית במיוחד כשמשתמשים במצב הכתיבה "הוספה בלבד", שבו כל השינויים שמתרחשים באמצע אמורים להישמר.- כשמטענים ייעודיים (payloads) של LOB שלא השתנו נמחקים מיומן ה-Redo במהלך
ב-Oracle 11g, טבלאות עם עמודות מסוגי הנתונים
ANYDATAאוUDTלא נתמכות, והטבלה כולה לא תשוכפל.Oracle Label Security (OLS) לא משוכפל.
בזמן עיבוד האירועים, Datastream מאחזר מדי פעם את הסכימה העדכנית מהמקור. אם סכימה משתנה, יכול להיות שחלק מהאירועים מהסכימה החדשה ייקראו בזמן שהסכימה הישנה עדיין מיושמת. במקרה כזה, Datastream מזהה את השינוי בסכימה, מפעיל אחזור של הסכימה ומעבד מחדש את האירועים שנכשלו.
לא כל השינויים בסכימת המקור ניתנים לזיהוי באופן אוטומטי, ובמקרה כזה עלולה להתרחש פגיעה בנתונים. השינויים הבאים בסכימה עלולים לגרום לפגיעה בנתונים או לכשל בעיבוד האירועים בהמשך:
- הסרת עמודות
- הוספת עמודות באמצע הטבלה
- שינוי סוג הנתונים של עמודה
- סידור מחדש של העמודות
- הסרת טבלאות (רלוונטי אם אותה טבלה נוצרת מחדש עם נתונים חדשים)
- חיתוך טבלאות
Datastream לא תומך בשכפול תצוגות.
Datastream לא תומך בשכפול של עמודות וירטואליות (
GENERATED ALWAYS AS (...) VIRTUAL), כי Oracle לא שומר ערכים של עמודות וירטואליות בדיסק ולא כותב אותם ביומני Redo. עמודות וירטואליות מושמטות מסכימת היעד. אם עמודה וירטואלית היא חלק ממפתח ראשי מורכב, Datastream משתמש רק בעמודות הלא וירטואליות כמפתח הראשי ביעד. אם העמודות הנותרות לא ייחודיות, זה יכול לגרום לדריסת מפתחות כפולים.Datastream תומך בתצוגות מהותיות. עם זאת, תצוגות חדשות שנוצרות בזמן שהשידור פועל לא מתמלאות באופן אוטומטי.
כשמשתמשים בשיטת Oracle LogMiner, אין תמיכה בהצהרות
SAVEPOINTוהן עלולות לגרום לאי-התאמה בנתונים במקרה של החזרה למצב קודם.כשמשתמשים בשיטת הקורא הבינארי, אין תמיכה בטבלאות מחולקות למחיצות באופן דינמי.
כשמשתמשים בשיטת Oracle LogMiner, Datastream לא תומך בשכפול טבלאות ועמודות שהשמות שלהן ארוכים מ-30 תווים.
Datastream תומך בקידודים הבאים של מערכות תווים למסדי נתונים של Oracle:
AL16UTF16AL32UTF8IN8ISCIIIW8ISO8859P8JA16SJISJA16SJISTILDEKO16MSWIN949US7ASCIIUTF8WE8ISO8859P1WE8ISO8859P9WE8ISO8859P15WE8MSWIN1252ZHT16BIG5
Datastream לא תומך בשכפול של ערכי תאריך אפס. תאריכים כאלה מוחלפים בערכי
NULL.Datastream לא תומך בקישוריות ישירה למסדי נתונים באמצעות התכונה Single Client Access Name (SCAN) בסביבות Oracle Real Application Clusters (RAC). למידע על פתרונות אפשריים, ראו התנהגות ומגבלות של מקור Oracle.
אם המקור הוא מסד נתונים במצב המתנה של Oracle Active Data Guard, Datastream תומך בהצפנה ברמת מרחב הטבלאות בלבד ולא בהצפנה ברמת העמודה.
מגבלות נוספות בשימוש בקורא הבינארי
השיטה של קורא בינארי עם ביצועים גבוהים נתמכת רק ב-Oracle 12c ואילך. בגרסאות Oracle 11g וגרסאות קודמות, צריך להשתמש ב-LogMiner.
הקורא הבינארי לא תומך בתכונות הבאות:
- הצפנת מסד נתונים שקופה (TDE)
- דחיסה היברידית של עמודות (HCC)
- קבצים מאובטחים
- אין תמיכה ב-ASM במקורות של Amazon RDS.
- שיטת ה-CDC של קורא בינארי לא תומכת ב-Oracle 11g ובגרסאות קודמות.