חלופה לרפליקציה

כל התגובות

• 

  

  2

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

  שלום

  יש הרבה חלופות לכל אחת יתרונות וחסרונות  הכל תלוי כמה מאמץ את מוכנה להשקיע ובאיזו גרסה של SQL Server  מדובר
  יש גם משמעות באיזה רשיון השרתים שלך  - חלק מהאפשרויות רלוונטיות רק ל Enterprise edition 

  Log shipping   - האפשרות הקלה ביותר   - http://technet.microsoft.com/en-us/library/ms190640.aspx

  Database Mirroring  קצת יותר מורכב  -http://technet.microsoft.com/en-us/library/ms189852.aspx

  Always-On  - אפשרי רק ב 2012 
  

  http://technet.microsoft.com/en-us/library/hh510230.aspx

  בכל האפשרויות לעיל  תקבלי את אותו DB בשרת השני  - אך ההבדל הוא באפשרויות recovery שונות במקרה שאחד השרתים נפל
  

  מקווה שעזרתי,
  נועם

  • הוצע כתשובה על-ידי Ivan Radchenko יום חמישי 15 אוגוסט 2013 04:49

  יום רביעי 14 אוגוסט 2013 08:01

  תגובה

  |

  ציטוט
• 

  

  2

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

  הי מיכל,

  בהמשך לתגובה של נועם, הנה עוד כמה אפשרויות:

  1. למה יש לך בכל טבלה Unique Index, אבל אין לך Primary Key? למה לא להמיר את ה-Unique Indexes ב-Primary Key? את לא מפסידה שום דבר חוץ מהיכולת להגדיר את העמודה כ-Nullable. אני הייתי פשוט מוסיף Primary Keys לכל הטבלאות ואז משתמש ב-Transactional Replication...

  2. את יכולה להשתמש ב-Merge Replication. הוא לא דורש שיהיה לך Primary Key, אבל הוא כן דורש כל מיני דברים אחרים...

  3. את יכולה לכתוב בעצמך תהליך שמסנכרן בין בסיסי הנתונים, באמצעות SSIS למשל. לצורך כך תצטרכי לממש מנגנון שמזהה שינויים בטבלאות המקור. בשביל זה את יכולה להשתמש ב-CDC או בטריגרים או בעמודת timestamp, וכו'.

  בהצלחה!

  -----------------------------
  גיא גלנצר
  יועץ ומדריך SQL Server
  Madeira - SQL Server Services
  http://www.madeira.co.il
  

  • סומן כתשובה על-ידי michal12 יום רביעי 14 אוגוסט 2013 13:58

  יום רביעי 14 אוגוסט 2013 11:55

  תגובה

  |

  ציטוט

  מנחה דיון
• 

  

  0

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

  תודה רבה לשניכם על הרעיונות.

  1. ניסינו בעבר log shipping אבל המנגנון קרס בכל פעם (מדובר בחיבור VPN  בין שני שרתים המצויים בארצות שונות).

  2. Database Mirroring - אני צריכה ששני האתרים יהיו פעילים ונגישים. שרת אחד הוא השרת התפעולי והשני משמש כאתר אינטרנט.

  3. Always-On - לא מתאפשר כיון שמדובר בגרסת 2008.

  4. בעניין ה- PK - זה כמובן הדבר הראשון שבדקתי. כרגע לא ניתן אישור להוספת PK לטבלאות מחשש ל"פגיעה" באפליקציה. אגב, קיים גם אינדקס ייחודי וגם not null.

  5. Merge Replication - למיטב ידיעתי אופציה זו מסנכרנת גם את ה- publisher וגם את ה- subscriber. אני צריכה לסנכרן כיוון אחד בלבד. האם יש דרך לקבוע זאת ב- merge replication?

  6. מדובר בכמה אלפי טבלאות... אני חוששת שפתרון SSIS'י יהיה מורכב ובעייתי. האם יש לכם נסיון בעניין?

  מה לגבי חילול אוטומטי של סקריפטי merge  - האם מומלץ?

  תודה רבה מראש על הסיוע,

  מיכל

  יום רביעי 14 אוגוסט 2013 14:07

  תגובה

  |

  ציטוט
• 

  

  0

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

  הי מיכל,

  מה דעתך על פתרון פשוט של Backup  וRestore 

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

  מקווה שעזרתי,
  נועם

  יום רביעי 14 אוגוסט 2013 14:47

  תגובה

  |

  ציטוט
• 

  

  1

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

  הי מיכל,

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

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

  כל פתרונות הזמינות (Log Shipping, Database Mirroring, AlwaysOn) לא מתאימים לצרכים שלך, מכיוון שהם מאפשרים במקרה הטוב שהשרת המשני יהיה פתוח לקריאה בלבד. אף אחד מהם לא מאפשר לך כתיבה בשרת המשני.

  בקיצור, לאור כל מה שסיפרת לנו עד כה, הנה מה שאני הייתי עושה (לפי סדר עדיפות):

  1. משכנע את המנהלים שלי להוסיף Primary Key לכל הטבלאות במקום ה-Unique Index, ומשתמש ב-Transactional Replication.

  2. כותב SSIS Package דינמי שמשתמש ב-CDC על מנת לסנכרן את כל הטבלאות.

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

  בהצלחה!

  -----------------------------
  גיא גלנצר
  יועץ ומדריך SQL Server
  Madeira - SQL Server Services
  http://www.madeira.co.il
  

  • הוצע כתשובה על-ידי Ivan Radchenko יום חמישי 15 אוגוסט 2013 05:00
  • סומן כתשובה על-ידי michal12 יום חמישי 15 אוגוסט 2013 07:54

  יום רביעי 14 אוגוסט 2013 21:15

  תגובה

  |

  ציטוט

  מנחה דיון
• 

  

  1

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

  מה זה?!? נעלמתי לכמה ימים וכבר כולם הספיקו לתת תשובות לכל השאלות?!?

  טוב לראות שלא חיכתם לי ואין לי הרבה מה להוסיף פרט לכך שני מסכים עם רוב מה שגיא כתב (אמרתי רוב)

  במבט ראשוני לפי מה שאני קורא בשרשור ובלי אפיון מלא נראה לי שהכיוון המתאים הוא להתחיל מסוף הדברים של גיא, למה בכלל בחרתם ב 2 שרתים?!?

  אחרי שנבין את התשובה נוכל להמשיך. אם השימוש בשרת שני נועד לגיבוי אז זה עניין אחד אבל אם בגלל חלוקת משאבים אז צריך לחשוב אם באמת הצלחתם לדגדג לשרת ה SQL את היכולות שלו (ואני בטוח שלא). חומרה תמיד אפשר לשפר וזה גם יותר זול מעוד רשיון בדרך כלל. אם הסיבה היא למשל תעבורה: לקוחות שנמצאים במיקום X ניגשים לשרת X ולקוחות במיקום Y ניגשים לשרת Y אז הרי שמדובר בסיבה מאוד חשובה אבל אז עובדים עם LOAD BAKLANCE בדרך כלל ויש לדאוג לסינכרון מלא.... בקיצור צריך להבין קודם כל מה ולמה הגעתם לאפיון בו אתם נמצאים ולא להתחיל מהסוף כיצד לבצע משהו שאולי לא מתאים לכם

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

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

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

  * הרבה מהרעיונות כאן יוצרים סינכרון מלא. לא הצלחתי להבין מהדיון אם זה המצב שאתם מחפשים. האם מסדי הנתונים צריכים להיות מסונכרנים לחלוטין או רק חלק מהאלמנטים צריכים להיות מסונכרים? אם הסינכרון מלא האם 2 המסדים ציכים להיות פעילים או רק אחד מהן (להכנסת/שינוי רשומות). זה מתקשר לסיבה שהחלטתם על 2 שרתים ולאפיון שלכם וזה חייב להיות חלק מרכזי מקבלת ההחלטה על הפתרון. חלק מהפתרונות כמו שגיא ציין לא מתאימים לצרכים שלכם אם אתם רוצים 2 מסדים פעילים למשל...

  אני מציע שתנסי לספק עוד אינפורמציה על האפיון

  ---

  

  • סומן כתשובה על-ידי michal12 יום חמישי 15 אוגוסט 2013 09:29
  • נערך על-ידי pituachMVP, Moderator יום ראשון 18 אוגוסט 2013 15:38 תיקון שגיאת כתיב

  יום חמישי 15 אוגוסט 2013 04:50

  תגובה

  |

  ציטוט

  מנחה דיון
• 

  

  0

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

  תודה רבה. מעריכה מאוד את עזרתכם הרבה!!

  הוחלט לבדוק שתי חלופות:

  1. בדיקה עם אנשי התוכנה האם אפשר להוסיף PK מבלי שיפגע במערכת (זו מערכת גנרית מותאמת לקוח). אם נקבל אישור נצטרך ליצור סקריפט ליצירת אלפי PK (כמספר הטבלאות) ולהריץ  אותו לאחר כל שדרוג גרסה. במקרה כזה כמובן שניישם את פתרון ה- transactional replication.

  2. בחירה ב- merge replication - אבל עם מגבלת סינכרון בכיוון אחד בלבד. ידוע לכם כיצד מבצעים זאת? האם יעמיס על שרת ה- production יותר מאשר transactional replication?

  תודה,

  מיכל

  אגב... נועם, לא ניתן לבצע backup ו- restore בכל פעם בשל גודל ה-DB והתעבורה האיטית (כפי שרשמתי מדובר על שרתים הממוקמים בארצות שונות. העברת גיבוי מכווץ - שהיתה אמורה לארוך 17 יום!!! - כשלה בגלל בעיית גודל..)

  יום חמישי 15 אוגוסט 2013 08:39

  תגובה

  |

  ציטוט
• 

  

  0

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

  הי,

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

  אין אפשרות לאחד את שני השרתים.

  הדרישה היא שיהיה סנכרון בין בסיסי הנתונים - לפחות פעם ביום.

  שני בסיסי הנתונים פעילים. באחד מעדכנים נתונים והשני משמש לקריאה בלבד.

  בעבר הופעל מנגנון Log shipping שלא צלח כיון שמדי פעם היו ניתוקים בתקשורת והסנכרון "נפל".

  הצענו לבצע רפליקציה חד כיוונית אבל כאמור כיון שאין PK זה לא מתאפשר.

  התחלתי לבדוק את הצעתו של גיא בעניין ה- merge replication עבור כיוון אחד בלבד. קראתי שזה אפשרי ע"י שינוי הפרמטר subscriber_upload_options והגדרת ה- subscriber כ- client (במקום כ- server).

  אני בודקת את האפשרות.

  אשמח לקבל הערות/הארות נוספות - גם לגבי ה- merge replication.

  יום טוב,

  מיכל

  יום חמישי 15 אוגוסט 2013 09:39

  תגובה

  |

  ציטוט
• 

  

  1

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

  הי מיכל,

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

  בסיפור הזה, ההמלצות שלי הן גם כן אחרות לגמרי:

  1. אם את עובדת עם Enterprise Edition, אז אני ממליץ להשתמש ב-Database Mirroring אסינכרוני בין השרתים, ואחת לכמה זמן ליצור Database Snapshot בשרת המשני. הבעיה כאן היא עם "אחת לכמה זמן". אם את יכולה להרשות לעצמך לנתק את האתר לרגע מבסיס הנתונים, לפחות פעם ביום, אז בנקודה הזאת את צריכה למחוק את ה-Database Snapshot הקודם וליצור אותו מחדש עם אותו שם. זאת פעולה קצרה יחסית, ומיד לאחר מכן האתר יוכל להתחבר שוב לבסיס הנתונים העדכני.

  2. אם את לא עובדת עם Enterprise Edition, אז אני ממליץ על Log Shipping. אני יודע שכתבת כאן שכבר ניסיתם את זה בעבר וזה לא הצליח, אבל אני ממליץ לבדוק ולהבין למה זה לא הצליח. אם היו ניתוקים בתקשורת, כמו שאת טוענת, אז תהיה לך בעיה בכל פתרון שתבחרי, וזה כולל Transactional Replication. לדעתי, לא צריכה להיות שום בעיה להשתמש ב-Log Shipping. הבעיה היחידה היא אותה בעיה שהזכרתי בסעיף הקודם. את צריכה לקבוע נקודות זמן במשך היום, שבהן מנתקים את האתר, משחזרים את הלוגים (Standby, כמובן), ומחזירים את האתר חזרה.

  3. אם את לא יכולה להרשות לעצמך לנתק את האתר אפילו לרגע, אז שני הפתרונות הקודמים לא מתאימים לך. במקרה כזה רפליקציה היא בדרך כלל התשובה. כאמור, עדיף להשתמש ב-Transactional Replication, אבל בשביל זה את צריכה לפתור את בעיית המפתחות שלכם. אם זה לא עובד, אז את יכולה בהחלט להשתמש ב-Merge Replication. כמו שציינת, את צריכה להגדיר את ה-Subscription כ-Client, ואת צריכה להגדיר את הפרמטר subscriber_upload_options@ עם הערך 2 (שאומר שאי אפשר לבצע שינויים ב-Subscriber). עוד פרטים כאן. אני לא אוהב את הפתרון של Merge Replication. הוא מוסיף לך עמודה מסוג UNIQUEIDENTIFIER וגם טריגרים לכל הטבלאות, והוא עלול להכביד על ביצועי המערכת שלך בצורה משמעותית. אבל זה בהחלט אפשרי...

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

  בהצלחה!

  -----------------------------
  גיא גלנצר
  יועץ ומדריך SQL Server
  Madeira - SQL Server Services
  http://www.madeira.co.il
  

  • סומן כתשובה על-ידי michal12 יום ראשון 18 אוגוסט 2013 05:54

  יום חמישי 15 אוגוסט 2013 19:12

  תגובה

  |

  ציטוט

  מנחה דיון
• 

  

  0

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

  שלום רב

  בתור אחד שמימש transactional replication ו- merger replication ע"ג Wan ביו עשרות שרתים אני ממש לא ממליץ על הפתרונות הללו או נסיונות לכתוב פתרונות כאלה.

  אם מדובר בשרתים שיש להם חשיבות תפעולית ועסקית לחברה , הייתי ממליץ על פתרון יקר אך שונה והטרוגני : Oracle Golden Gate .

  עיני תחת

  דוד יצחק DBA

  יום רביעי 21 אוגוסט 2013 18:53

  תגובה

  |

  ציטוט
• 

  

  0

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

  חפשי בגוגל את ההרצאה האחרונה שלי בנושא תחת

  דוד יצחק DBA  golden gate

  יום רביעי 21 אוגוסט 2013 18:53

  תגובה

  |

  ציטוט