בעיית רפליקציה

כל התגובות

• 

  

  1

  היכנס כדי להצביע

  ברור לך שהמידע כאן לא מספיק אפילו לניחוש מושכל? כל מה שאנחנו יכולים לבצע זה ניחוש מוחלט!

  לפי ההודעה נשמע שהבעיה קשורה להמרה של ערך שרשרת טקסט לסוג BIT. זו דווקא תופעה שיכולה לקרות לסירוגין. כיצד זה קורה לפעמים? אפשרות פשוטה אחת במסגרת הניחושים היא שמדובר בטור בטבלה שבדרך כלל מקבל מידע שמתאים להמרה לBIT כמו 1 או 0 (השרת יודע לבצע פעולה שנקראת בפיתוח המרה מרומזת), ומפעם לפעם יש שם ערך טקסטואלי או מספר גדול מ 1 ולכן ההודעה מגיעה. זה כמובן סתם זריקה באויר של אפשרות :-)

  החלק היותר חשוב הוא כניראה יהיה לנטר את הבעיה. בשלב הראשון הייתי מנסה להשוות את מסדי הנתונים (את הטבלאות מקור והיעד), אבל העובדה שאתה מרמז על כך שאתה לא יכול לאתר את הטבלה (המאמר) מקשה קצת מכיוון ששמסדי הנתונים לא חייבים זהים כמובן בצורה כוללת, ולכן סריקה מלאה יכולה לא להתאים. לכן כשלב ביניים כשאתה צריך לנטר את הבעיה, דווקא ב TRANSNATIONAL REPLICATION יותר קלה לנטר מפעולות אחרות לפעמים מפני שנקודת הזמן שיש בעיה מצביעה על נקודת הזמן שהדטא הישתנה (סביבות נקודת הזמן) ולכן מרמז על הדטא עצמו שקשור לבעיה. נסה לנטר את נקודת הזמן של הבעיה ומכאן להגיע למקור. אם זה שרת לא עמוס ואין לך בעיה לעבוד הלכביד עליו (לא מומלץ בעקרון וה במסגרת הניחושים) אז אתה יכול לנטר בעזרת אירועים מורחבים (Event Session) או CDC או כל ניטור אחר שיתעד שינויים של ה DML (אותם שינויים שיעברו ברפליקציה). אפשרות נוספת זה לחקור את קובץ הלוג רטרואקטיבית כאשר מופיעה הבעיה ולנסות לאתר את העיה בפעולות האחרונו שבוצעו.

  ---

  [Personal Site]  [Blog]  [Facebook]
  

  יום שני 13 אוקטובר 2014 20:37

  תגובה

  |

  ציטוט

  מנחה דיון
• 

  

  1

  היכנס כדי להצביע

  היי

  אתה יכול להשתמש בסקריפט הבא:

    
  Use distribution;
  
  Declare @PublisherDB sysname,
        @PublisherDBID int,
        @SeqNo nchar(22),
        @CommandID int
  
  -- Set publisher database name and values from Replication Monitor
  
  Set @PublisherDB = N'databasename'
  Set @SeqNo = N'0x0032B314000042F9002600000000'
  Set @CommandID = 1
  
  -- Find the publisher database ID
  
  Select @PublisherDBID = id
  From dbo.MSpublisher_databases
  Where publisher_db = @PublisherDB
  
  -- Get the command
  
  Exec sp_browsereplcmds
        @xact_seqno_start = @SeqNo,
        @xact_seqno_end = @SeqNo,
        @command_id = @CommandID,
        @publisher_database_id=@PublisherDBID;  
       
  

  בהצלחה!

  אסף אביב

  
  

  • הוצע כתשובה על-ידי pituachMVP, Moderator יום שלישי 14 אוקטובר 2014 09:04
  • סומן כתשובה על-ידי Eran Sharvit יום ראשון 19 אוקטובר 2014 08:57

  יום שלישי 14 אוקטובר 2014 07:21

  תגובה

  |

  ציטוט
• 

  

  0

  היכנס כדי להצביע

  יוסי, אתה יכול לעדכן אותנו מה קורה עם השאלה, ואם אפשר לסגו את השרשור?

  תודה

  ---

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

  יום שישי 17 אוקטובר 2014 06:56

  תגובה

  |

  ציטוט

  מנחה דיון
• 

  

  0

  היכנס כדי להצביע

  איזה נתונים יכולים לעזר בניתוח הבעיה? (אני יכול לצרף)

  השאילתה לא מחזירה כלום - ואתמול קבלתי עוד הודאת שגיאה של:

  *הבעיה נפתרת ברגע שמורידים את הSUBSCRIBER ומוסיפים אותו בחזרה ומאתחלים את הSNAPSHOT

  יום שלישי 21 אוקטובר 2014 06:13

  תגובה

  |

  ציטוט
• 

  

  0

  היכנס כדי להצביע

  t,v hfuk Pרםכןךקר עם ניטור שגיאות על ה-subscriber כדי לראות איפה הוא נופל

  יום ראשון 23 נובמבר 2014 17:01

  תגובה

  |

  ציטוט
• 

  

  2

  היכנס כדי להצביע

  הביעה נפתרה מזמן - רק עכשיו התפנתי להעלות את הבעיה והפתרון.

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

  הבעיה:

  טבלה שרופלקה לDB עם טבלה קיימת עם אותו שם. (טבלה אחרת)

  כלומר DB1.T1 רופלק ל DB3.T1 כאשר T1 קיים בשם (טבלה אחרת) אך גם הוא מרופלק מ DB אחר נגיד DB2

  כמובן שזה יוצר התנגשות ולכן פיצלו את הטבלאות ביעד ל: (ניתן לשנות ברמת הקונפיגורציה של הרפליקציה)

  • DB1.T1 to DB3.T1
  • DB2.T1 to DB3.T1_2

  לכאורה פותר את הבעיה - אך יוצר בעיה חדשה (זאת הבעיה שהיתה לנו)

  אם לא דואגים לשנות את הקונפיגורציה שמגדירה את הפרוצדורת שמעתיקות את הנתונים אז שתי בטבלאות יסתמכו על אותם פרוצדורת (השם בררית מחדל נגזר משם הטבלת המקור T1)

  כך שלמעשה הפרוצדורה [sp_MSins_dboT1] הופעלה גם לגבי DB1.T1 וגם לגבי DB2.T1.

  

  * בצילום טבלת roles (אבל אותו רעיון)

  מכיוון שלמזלנו מבנה הטבלות לא היה זהה - כבלנו שגיאה עבור DB2.T1 (אחרת השינויים היו "דורסים" את השינויים של DB1.T1)

  הפתרון:

  היו שני אפשרויות לפתרון ההתנגשות:

  1. להוסיף פרוצדורה עם שם שונה.

  2. לשנות את שיטת העברת הנתונים ל SQL.

  בחרנו בפתרון השני - גם מכיוון שאלה טבלאות קטנות יחסית.

  

  \יוסי

  • סומן כתשובה על-ידי pituachMVP, Moderator יום חמישי 11 דצמבר 2014 11:48

  יום חמישי 11 דצמבר 2014 09:44

  תגובה

  |

  ציטוט