הזרמת נתונים ממסדי נתונים של SQL Server

כדי לסנכרן את מסדי הנתונים של ניתוח הנתונים ושל הנתונים במורד הזרם, אתם יכולים להשתמש ב-Datastream כדי לשכפל נתונים היסטוריים ושינויים שוטפים ממסד נתונים של SQL Server.

למקורות של SQL Server ב-Datastream, כדאי לעיין בשיטות של התנהגות הרפליקציה וסימון נתונים שהשתנו (CDC), בגרסאות ובמהדורות הנתמכות ובמגבלות הידועות.

התנהגות

Datastream עוקב אחרי שינויים בשפת הטיפול בנתונים (DML) באמצעות אחת מהשיטות הבאות של CDC:

• שינוי טבלאות
• יומני טרנזקציות

שינוי טבלאות

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

כשמשתמשים בשיטת ה-CDC הזו, השינויים במקור מתועדים בטבלאות שינויים ייעודיות. עדיין משתמשים ביומני טרנזקציות, אבל במידה מוגבלת, ואין צורך לשמור אותם לתקופות ארוכות יותר. כשאירועי DML מוחלים על טבלאות המקור, השינויים משוכפלים לטבלאות השינויים המתאימות. לטבלאות השינויים יש מבנה זהה לזה של טבלאות המקור, אבל יש בהן עמודות נוספות שכוללות את המטא-נתונים של השינויים. רק טרנזקציות שבוצעו מתווספות לטבלאות השינויים, יחד עם מספר סידורי ביומן (LSN) של פעולת ה-commit.

הערה: כשמתחילים סטרימינג, Datastream בוחר את מופע תיעוד הנתונים האחרון כדי לשכפל ממנו את השינויים. אם נוצר מופע תיעוד חדש אחרי שהתחיל ה-stream, ‏Datastream לא עובר אליו באופן אוטומטי. אם מופע ה-capture שנבחר נמחק, Datastream מדלג על הקריאה של טבלת השינויים התואמת.

איך Datastream מטפל בשינויי DDL בסכימת המקור

כשמשתמשים בשיטת ה-CDC של טבלאות שינויים, נוצרים מופעי תיעוד לכל טבלת שינויים. כל מופע של תיעוד משויך לרשימת עמודות שהוא מתעד ועוקב אחריהן. כברירת מחדל, כשמתרחש שינוי בשפת הגדרת הנתונים (DDL) במקור אחרי שנוצר מופע תיעוד השינויים, המופע מתעלם מהשינוי. עם זאת, אתם יכולים להגדיר את הסטרימינג של SQL Server כך שישכפל עמודות שנוספו לסכימת המקור אחרי שנוצרו הסטרימינג והמופע של תיעוד השינויים.

לפני שמתחילים

• מוודאים שלמשתמש ב-Datastream הוקצתה ההרשאה db_owner.

שכפול עמודות שנוספו לסכימת המקור

כדי ש-Datastream יתמוך בשכפול עמודות שנוספו לסכימת המקור אחרי שנוצר מקור נתונים, צריך להוסיף את התווית enable_ddl_support_for_ct למקור הנתונים:

1. נכנסים לדף Streams במסוף Google Cloud .

   מעבר לדף Streams

2. לוחצים על מקור הנתונים של SQL Server שרוצים לערוך.

3. בדף פרטי השידור, לוחצים על השהיה.

4. לוחצים על עריכה > עריכת הגדרות השידור.

5. לוחצים על הוספת תווית.

6. בשדה Key, מקלידים enable_ddl_support_for_ct.

7. בשדה Value, מקלידים true.

8. לוחצים על Save.

9. כדי להמשיך בשידור, לוחצים על התחלה.

‫Datastream בודק את הטבלה cdc.ddl_history אם יש DDL חדשים כל חמש דקות. אם נוספה עמודה חדשה לטבלה שנכללת בהגדרת מקור הנתונים, Datastream בודק אם לטבלה יש שני מופעי תיעוד:

• אם לא, Datastream יוצר מופע תיעוד חדש, קורא את נתוני מופע התיעוד המקורי עד לרגע שבו התרחש ה-DDL, ואז מתחיל לקרוא ממופע התיעוד החדש.

  הערה: אחרי ש-Datastream יוצר את מכונת תיעוד השינויים החדשה, צריך למחוק את המכונה המקורית. ב-SQL Server אפשר להשתמש בשני מופעי תיעוד לכל היותר לכל טבלה, ולכן צריך למחוק את המופע הישן כדי לאפשר שינויים עתידיים ב-DDL.

• אם כן, נוספת רשומת יומן שבה מצוין שלא ניתן לטפל בשינוי ה-DDL כי הגעתם למספר המקסימלי של מופעי תיעוד.

יומני עסקאות

כשמשתמשים בשיטת ה-CDC הזו, Datastream קורא את השינויים במקור ישירות מיומני העסקאות. השיטה הזו דורשת פחות משאבים ומאפשרת לאחזר נתונים מהר יותר, אבל יש לה יותר מגבלות.

כדי למנוע אובדן נתונים, חשוב שהיומנים לא ייחתכו לפני ש-Datastream יקרא אותם. מצד שני, אם שומרים את קובצי היומן יותר מדי זמן, הם תופסים מקום אחסון, ובסופו של דבר המכונה של מסד הנתונים עלולה להיכנס למצב קריאה בלבד.

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

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

גרסאות

‫Datastream תומך בגרסאות ובמהדורות הבאות של מסדי נתונים ב-SQL Server:

• בניהול עצמי (במקום או בענן) בגרסאות הבאות:
  • ‫Enterprise: ‏ 2008 ואילך
  • ‫Standard: ‏ 2016 SP1 ואילך
  • מפתח: 2008 ואילך
• Amazon RDS ל-SQL Server

• ‫Azure SQL Database (רמה S3 ומעלה).

  הערה: האפשרות הזו נתמכת רק כשמשתמשים בשיטת ה-CDC של טבלאות השינויים.

• Cloud SQL ל-SQL Server

‫Datastream לא תומך בגרסאות הבאות של מסדי נתונים של SQL Server:

• ‫SQL Server Standard מגרסה 2008 עד 2014
• SQL Server Express
• SQL Server Web

מגבלות ידועות

המגבלות הידועות בשימוש במסד נתונים של SQL Server כמקור כוללות:

• הסטרימינג מוגבל ל-10,000 טבלאות.
• אי אפשר למלא לאחור טבלה עם יותר מ-500 מיליון שורות, אלא אם מתקיימים התנאים הבאים:
  1. לטבלה יש אינדקס ייחודי.
  2. אף אחת מעמודות האינדקס לא יכולה להיות ריקה.
  3. כל העמודות של האינדקס נכללות בסטרימינג.
• אין תמיכה במסדי נתונים שמופעלת בהם עמידות מושהית או שחזור מואץ של מסד נתונים (ADR).
• אי אפשר להעביר בסטרימינג שינויים בטבלאות המערכת.
• אין תמיכה באימות של Windows Active Directory ‏ (AD).

• ‫Datastream תומך בכל ההשוואות של SQL Server, חוץ מאלה עם דף הקוד 0. כדי לבדוק את דף הקוד של אוסף ספציפי, מריצים את השאילתה הבאה במכונה של SQL Server:

  SELECT *, CAST(COLLATIONPROPERTY(name, 'CodePage') AS INT) FROM sys.fn_helpcollations() WHERE name = COLLATION_NAME;
  

• סוגי הנתונים הבאים לא נתמכים ולא משוכפלים ליעד:

  • SQL_VARIANT
  • HIERARCHYID
  הערה: בסטרימים שנוצרו לפני שנוספה ל-Datastream תמיכה בסוגי נתונים מרחביים, העמודות GEOMETRY ו-GEOGRAPHY לא משוכפלות כברירת מחדל. כדי להפעיל שכפול של עמודות GEOMETRY ו-GEOGRAPHY בסטרימינג קיים, צריך להוסיף לסטרימינג את התווית enable_sqlserver_spatial_types עם הערך true.

• ‫Datastream משכפל סוגי נתונים שמוגדרים על ידי המשתמש, אבל סוג הנתונים הבסיסי שממנו נגזר הסוג שמוגדר על ידי המשתמש הוא זה שמאוחסן ביעד. לדוגמה, אם מגדירים סוג נתונים USERNAME על סמך סוג הנתונים VARCHAR(50), הנתונים מאוחסנים ביעד כ-VARCHAR(50).

• ‫Datastream לא תומך ב-CDC לעמודות של אובייקטים גדולים (TEXT, NTEXT, XML, IMAGE, GEOMETRY, GEOGRAPHY) ולעמודות עם אורך משתנה מקסימלי (VARCHAR(MAX), VARBINARY(MAX), NVARCHAR(MAX)) בטבלאות בלי אינדקס ייחודי.

  אם עמודות של אובייקטים גדולים לא נכללות בסטרימינג, יש תמיכה ב-CDC.

• כשמשתמשים בשיטת ה-CDC של טבלאות שינויים, אין תמיכה בשכפול של השינויים הבאים בסכימת המקור, והם עלולים לגרום לפגיעה בנתונים או לכשל בעיבוד האירועים:

  • הסרת עמודות: הנתונים בעמודות האלה מוחלפים בערכי NULL.
  • שינוי שמות של עמודות: לא נתמך ב-SQL Server כש-CDC מופעל.

  • שינוי סוגי נתונים: משימת תיעוד ה-CDC של SQL Server מפיצה רק את השינויים הבאים בסוגי הנתונים:

    • שינוי האורך המקסימלי של מחרוזות: למשל, שינוי סוג הנתונים VARCHAR(50) ל-VARCHAR(100). לעמודה STRING ב-BigQuery אין אורך קבוע, והיא מקבלת את המחרוזת הארוכה יותר.
    • הגדלת הטווח של ערך המספר השלם: לדוגמה, שינוי סוג הנתונים INT ל-BIGINT. סוג הנתונים INT64 ב-BigQuery מתאים לסוג החדש בלי שצריך לשנות את הסכימה.
    • שינוי הדיוק והקנה מידה של ערכים מספריים: לדוגמה, שינוי סוג הנתונים DECIMAL(10, 2) ל-DECIMAL(18, 4). לסוג NUMERIC ב-BigQuery יש דיוק קבוע גדול (38) וקנה מידה (9), ושינוי כזה נתמך.

    בשינויים אחרים של סוגי נתונים, Datastream מנסה להוסיף את הנתונים ליעד ומציג שגיאה אם הנתונים נדחים.

• ב-Datastream אין תמיכה בשכפול טבלאות שכוללות עמודות עם הסתרת מידע. הנתונים משוכפלים בלי הסתרה.

• ב-Datastream אין תמיכה ברפליקציה של שינויים שבוצעו במסד הנתונים באמצעות חבילת Data Tier Application Package‏ (DACPAC).

• ‫Datastream לא משכפל שינויים שבוצעו באמצעות ההצהרות WRITETEXT או UPDATETEXT.

• אם אתם משתמשים בתווית enable_ddl_support_for_ct כדי לשכפל עמודות שנוספו לסכימת המקור, אתם לא יכולים לצרף כמה מקורות נתונים לאותה טבלת מקור ב-SQL Server. ב-SQL Server אפשר להגדיר עד שני מופעי תיעוד לכל טבלה, ולכן שינויים בסכימה עלולים לגרום למרוץ תהליכים שבו Datastream מנסה ליצור מופעי תיעוד, וכתוצאה מכך הסטרימינג עלול להיכשל.

• ‫Datastream לא תומך בשכפול של עמודות מחושבות, אלא אם העמודה מסומנת כ-PERSISTED.

• ב-Datastream אין תמיכה בסוגי הדחיסה PAGE, ‏ COLUMNSTORE או COLUMNSTORE ARCHIVE.

מגבלות נוספות כשמשתמשים בשיטת יומני העסקאות

אם אתם משתמשים בשיטת CDC של יומני טרנזקציות, חלות המגבלות הנוספות הבאות:

• אין תמיכה בהצפנת נתונים שקופה (TDE).
• אין תמיכה בהצפנה ברמת העמודה. הנתונים בעמודות האלה מוחלפים בערכים של NULL.
• כשמשתמשים בשיטת CDC של יומני טרנזקציות, Datastream לא תומך בשכפול עמודות שנוספו לסכימת המקור אחרי שנוצר הסטרים. העמודות החדשות לא משוכפלות ליעד.
• ‫Datastream לא תומך בהצהרה ROLLBACK TO SAVEPOINT. המערכת מתעלמת מאירועי החזרה כאלה והם לא משוכפלים ליעד.
• ‫Datastream לא תומך ב-CDC לשורות שגדולות מ-8KB בסוגי הטבלאות הבאים:
  • טבלאות בלי אינדקס ייחודי
  • טבלאות שמכילות רק אינדקס ייחודי ולא מקובץ, עם עמודה אחת או יותר באורך משתנה (VARCHAR, ‏ VARBINARY, ‏ NVARCHAR, ‏ GEOMETRY,‏ GEOGRAPHY)

• ‫Datastream לא תומך ב-CDC לעמודות של אובייקטים גדולים (TEXT, NTEXT, XML, IMAGE, GEOMETRY, GEOGRAPHY) בסוגי הטבלאות הבאים:

  • טבלאות בלי אינדקס ייחודי
  • טבלאות שמכילות רק אינדקס ייחודי ולא מקובץ, עם עמודה אחת או יותר באורך משתנה (VARCHAR, ‏ VARBINARY, ‏ NVARCHAR, ‏ GEOMETRY,‏ GEOGRAPHY)

  אם עמודות של אובייקטים גדולים לא נכללות בסטרימינג, CDC נתמך בטבלאות כאלה רק אם יש להן אינדקסים תקינים.

• כשמשתמשים בשיטת יומני העסקאות, Datastream שולח שאילתות למסד הנתונים של המקור כדי לאחזר ערכים חסרים בנקודת זמן מסוימת בתהליך חיפוש פעיל שנקרא השלמה. ההשלמה חלה על סוגי הנתונים XML,‏ TEXT,‏ NTEXT,‏ IMAGE,‏ GEOMETRY ו-GEOGRAPHY, ועל סוגים באורך משתנה כמו VARCHAR(MAX) או VARBINARY כשהשורות חורגות ממגבלת הדף של 8KB. ‫Datastream משלים את העמודות האלה באמצעות שליחת שאילתות למסד הנתונים, ולכן יכול להיות ששינויים זמניים לא יתועדו בתרחישים שכוללים עדכונים מהירים בזה אחר זה, או מחיקה מהירה אחרי הוספה. פעולות DELETE לא מפעילות השלמה. המגבלה הזו רלוונטית במיוחד כשמשתמשים במצב הכתיבה "הוספה בלבד", שבו כל השינויים שמתרחשים באמצע אמורים להישמר.

המאמרים הבאים

• איך מגדירים מקור SQL Server לשימוש עם Datastream