managing transaction log

[flenger]

managing transaction log

שלום לכולם אומנם שאלתי שאלה באותו נושא אך רציתי לדעת
אם יש דרך לבצע שאילתות ללא ה TRANSACTION LOG
כלומר יש סקריפט שרץ בשביל לעדכן את הDATABASE שלי וחלק מסויים מבצע שינויים על טבלה גדולה מאוד אשר מנפחת מאוד את קובץ הLOG
רציתי לדעת אם יש דרך כלשהי באופן "זמני" למנוע את אותה כתיבה לקובץ LOG וכך למנוע את ההתנפחות

אני כמובן מודע לכך שבמידה ואני לא מבצע כתיבה לLOG אני לא אוכל לבצע ROLLBACK אך אני מוכן לקחת את זה בחשבון

תודה לעוזרים

 

[גרי רשף]

אין אופציה כזו

אין אופציה לגרום ל-SQL Server לא להיות טרנזקציוני..

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

נסה לציין פרטים נוספים על טיב הפעולות שהסקריפט מבצע (מוחק? מוסיף? יוצר אובייקטים?) ועל המערכת.

 

[pitoach]

אולי הבלוג הקטן הישן הזה יעזור לך

http://ariely.info/Blog/tabid/83/EntryId/79/SELECT-INTO-BULK-INSERT-vs-INSERT-INTO.aspx

* נראה בכלל לפי מה שאתה מתאר שאולי כדאי ומתאים לכם לעבור לעבוד ב simple recovery mode

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

 

[flenger]

אוקי , מצאתי פתרון או לפחות ככה זה נראה

תודה קודם לגרי ופיתוח

אז ככה ממה שבקדתי ומאיך שזה נראה לפחות המעבר ל RECOVERY MODE SIMPLE
לא משפיע על הגדילה של הLOG אחרי הכל עדיין מתאפשר לבצע ROLLBACK במצב הזה
אני מניח שזה קשור לביצוע TRANSACTIONS עם ROLLBACK במידת הצורך ( אני לא בטוח עד כמה הבנתי את זה )

כמו שאמרתי בעבר יש פתרון אחד AUTO SRHINK שמבצע SHRINK בעת הצרוך אחרי כל TRANSACTION
הבעיה שלי שהLOG מתנפח כל לך שצריך לצמצם אותו באמצע העדכון של הטבלה
אז מה שעשיתי

בניתי את אותה שאילתא שמעדכנת את הטבלה ה"בעייתי" עם WHILE שעובר על כל רשומות ובכל פעם אני לוקח כ 100K רשומות
ומבצע פקודת SHINK
כככה אני תמיד שומר על DB נקי ולא מנופח
ואם יש כישלון באחת האיטרציות יש אפשרות לROLLBACK

 

[pitoach]

האם קראת את הקשר של BULK INSERT ולMODE

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

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

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

2. אם עברת למצב SIMPLE ועתה תעבוד עם BULK INSERT אז כפי שהבלוג מסביר לא ירשמו הנתונים בכלל ב LOG וכמובן שלא יהיה לבצע חזרה אחורה. מוסבר שם מה כן ירשם וזה זניח

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

* כמובן שיכול להיות שזה לא מתאים למקרה שלך אבל אני עדיין חושב ששווה להשקיע עוד כמה דקות לבדוק אם אפשר להימנע מכיווך בכוח ומדרך שבחרת

קבל חח על הצגת הפתרון שלך

זה תמיד יכול לבאים

 

[flenger]

אני מודה שאני איבדתי את השפיות שלי בגלל זה

אני נתקלתי בקישור הזה כשניסיתי לחפש את הפתרון לבעיה שלי

כי הסיבה לבעיה היא החלטה ממש שגויה לדעתי
שבלתי אפשרי (לפחות כרגע לחזור אחורה)
פשוט לקחו טבלה גדולה מאוד שגוי לדעתי החליפו שדה ID בGUID מדובר על טבלה עם מליוני רשומות
מה שכמובן גרם לניפוח של הLOG לגדלים מפלתציים
אפילו שהשתמשתי בSIMPLE MODE עדיין זה לא עזר

בגדול גם הפיתרון שלי הוא לא חסין כי יכולים להיות מצבים שבטווח שנתתי יש המון רשומות מה ששוב יכול לגרום לניפוח של הLOG
אבל זה חצי נחמה

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

 

[pitoach]

בעיה מוכרת