none
בעיית רפליקציה RRS feed

  • שאלה

  • שלום,

    אנחנו משתמשים ב TRANSNATIONAL REPLICATIO

    ומידי פעם מקבלים את ההודעת שגיאה:

    "Command attempted:

    if @@trancount > 0 rollback tran
    (Transaction sequence number: 0x00046787000EA862002000000000, Command ID: 1)

    Error messages:
    Error converting data type nvarchar to bit. (Source: MSSQLServer, Error number: 8114)
    Get help: http://help/8114"

    אני מבין את המשמעות של ההודאה, אבל:

    אן לי מושג מאיזה ARTICLE זה מגיע ולמה זה קורה לסרוגין (בד"כ עובד טוב)

    אגב: הפקודה:

    EXECUTE distribution.dbo.sp_browsereplcmds

    לא החזירה כלום

    תודה,

    יוסי

    Microsoft SQL Server 2014 - 12.0.2000.8 (X64) 

    Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)



    • נערך על-ידי Yossi Drori יום שני 13 אוקטובר 2014 14:38
    יום שני 13 אוקטובר 2014 14:37

תשובות

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

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

    הבעיה:

    טבלה שרופלקה ל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, Editor יום חמישי 11 דצמבר 2014 11:48
    יום חמישי 11 דצמבר 2014 09:44
  • היי

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

      
    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, Editor יום שלישי 14 אוקטובר 2014 09:04
    • סומן כתשובה על-ידי Eran Sharvit יום ראשון 19 אוקטובר 2014 08:57
    יום שלישי 14 אוקטובר 2014 07:21

כל התגובות

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

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

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


    [Personal Site]  [Blog]  [Facebook]
    signature

    יום שני 13 אוקטובר 2014 20:37
    מנחה דיון
  • היי

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

      
    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, Editor יום שלישי 14 אוקטובר 2014 09:04
    • סומן כתשובה על-ידי Eran Sharvit יום ראשון 19 אוקטובר 2014 08:57
    יום שלישי 14 אוקטובר 2014 07:21
  • יוסי, אתה יכול לעדכן אותנו מה קורה עם השאלה, ואם אפשר לסגו את השרשור?

    תודה


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

    יום שישי 17 אוקטובר 2014 06:56
    מנחה דיון
  • איזה נתונים יכולים לעזר בניתוח הבעיה? (אני יכול לצרף)

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

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

    יום שלישי 21 אוקטובר 2014 06:13
  • t,v hfuk Pרםכןךקר עם ניטור שגיאות על ה-subscriber כדי לראות איפה הוא נופל
    יום ראשון 23 נובמבר 2014 17:01
  • הביעה נפתרה מזמן - רק עכשיו התפנתי להעלות את הבעיה והפתרון.

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

    הבעיה:

    טבלה שרופלקה ל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, Editor יום חמישי 11 דצמבר 2014 11:48
    יום חמישי 11 דצמבר 2014 09:44