none
עמודת IDENTITY ברפליקציה כפולה RRS feed

  • שאלה

  • שלום לכולם

    הגדרתי רפליקציה משרת א לשרת ב כשבאחת הטבלאות קיימת עמודת IDENTITY. כדי שהרפליקציה תעבוד הייתי צריך ביעד להגדיר את העמודה הזו עם

    not for replication = no.

    כעת ניסיתי להגדיר רפליקציה משרת ב לשרת ג. SQL אוטומטית החזיר את העמודה הנ"ל ל  not for replication = yes.

    השינוי האוטמוטי מנע את הרפליקציה עם הודעת שגיאה 544.

    השינוי הזה אירע גם אם החרגתי את העמודה הנ"ל מהרפליקציה.

    כל תשובה תתקבל בתודה.

    אריה.


    אריה שטרן

    יום חמישי 02 יוני 2016 13:51

תשובות

  • תבדוק אם הבלוג הבא עוזר לך:
    https://www.simple-talk.com/sql/database-administration/the-identity-crisis-in-replication/

    במבט ראשון (לא התעמקתי בנושא ולא ממש הבנתי מה הארכיטקטורה המלאה שלכם), נראה שמה שקרה זה שהרפלקיציה ראשונה שלכם מ A ל B ניהלה את הטווחים של ה IDENTITY בצורה נכונה אבל זה אורמ שהיא גם דאגה להכניס ערכים לטבלה B ועתה כאשר אתה מבצע רפליקציה נוספת הערכים לא מנוהלים על ייד הרפליקציה השנייה מפני שהרפליקציה ראשונה מנהלת אותם ולכן נוצרת בעיה של הכנסת ערך לטור IDENTITY

    * דרך אגב הרבה מאוד מהבעיות של הIDENTITY אפשר לעקוף בעזרת שימוש ב sequence שמנוהל ברמה של כל הטבלאות ביחד והרבה יותר גמיש

    ** אפשרות לפתרון היא במקום לעבוד עם ניהול אוטומטי, לעבוד עם ניהול ידני של הטווחים של ה IDENTITY (יש שלוש אפשרויות לניהול הטווחים של ה IDENTITY ברפליקציה, בדרך כלל אוטומטי זו הדרך המתאימה אבל במקרה שלך הרפליקציה השנייה תלויה ברפליקציה הראשונה).

    *** אפשרות נוספת שאני רואה זה שינוי הארכיטקטורה של הרפליקציה. למשל במקום רפליקציה לש A ל B ואז B ל C לבצע רפליקציה של A ל B וכן A ל C. אם יש מידע נוסף ב B שצריך לעבור ל C ולא מגיע מ A אז אפשר לבצע רפליקציה שלו בלבד על ידי סינון (צריך להביןו בדיוק מה הקונפיגורציה של המערכת לפני שאני ממלית על משהו, למשל המ מידע נכנס ולהיכן, וכיצד עובדים עם כל שרת מבחינת הכנסת,עדכון, וקריאת נתונים בעיקר).


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]



    יום שישי 03 יוני 2016 04:01
    מנחה דיון

כל התגובות

  • תבדוק אם הבלוג הבא עוזר לך:
    https://www.simple-talk.com/sql/database-administration/the-identity-crisis-in-replication/

    במבט ראשון (לא התעמקתי בנושא ולא ממש הבנתי מה הארכיטקטורה המלאה שלכם), נראה שמה שקרה זה שהרפלקיציה ראשונה שלכם מ A ל B ניהלה את הטווחים של ה IDENTITY בצורה נכונה אבל זה אורמ שהיא גם דאגה להכניס ערכים לטבלה B ועתה כאשר אתה מבצע רפליקציה נוספת הערכים לא מנוהלים על ייד הרפליקציה השנייה מפני שהרפליקציה ראשונה מנהלת אותם ולכן נוצרת בעיה של הכנסת ערך לטור IDENTITY

    * דרך אגב הרבה מאוד מהבעיות של הIDENTITY אפשר לעקוף בעזרת שימוש ב sequence שמנוהל ברמה של כל הטבלאות ביחד והרבה יותר גמיש

    ** אפשרות לפתרון היא במקום לעבוד עם ניהול אוטומטי, לעבוד עם ניהול ידני של הטווחים של ה IDENTITY (יש שלוש אפשרויות לניהול הטווחים של ה IDENTITY ברפליקציה, בדרך כלל אוטומטי זו הדרך המתאימה אבל במקרה שלך הרפליקציה השנייה תלויה ברפליקציה הראשונה).

    *** אפשרות נוספת שאני רואה זה שינוי הארכיטקטורה של הרפליקציה. למשל במקום רפליקציה לש A ל B ואז B ל C לבצע רפליקציה של A ל B וכן A ל C. אם יש מידע נוסף ב B שצריך לעבור ל C ולא מגיע מ A אז אפשר לבצע רפליקציה שלו בלבד על ידי סינון (צריך להביןו בדיוק מה הקונפיגורציה של המערכת לפני שאני ממלית על משהו, למשל המ מידע נכנס ולהיכן, וכיצד עובדים עם כל שרת מבחינת הכנסת,עדכון, וקריאת נתונים בעיקר).


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]



    יום שישי 03 יוני 2016 04:01
    מנחה דיון
  • רונן,

    שלום

    הרעיון להשתמש ב SEQUENCE עבד פלאים

    תודה

    אריה


    אריה שטרן

    יום ראשון 05 יוני 2016 10:32
  • אני שמח לשמוע :-)

    * דרך אגב כדאי לזכור שגם האפשרות השנייה עובדת, אבל היא היתה מחייבת יותר עבודה. אני מניח שגם הייתי בוחר באפשרות הראשונה :-)


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]

    יום ראשון 05 יוני 2016 14:16
    מנחה דיון