გოდეს ინტერნეტ დავთარი

ვაგრძელებთ თემებს ციკლიდან “ოჰ ეს Microsoft” არ ვიცი თქვენ რამდენად შეხებიხართ/გაწუხებთ ეს პრობლემა, მაგრამ  ბოლო პერიოდია, ერთ–ერთ სერვერზე, ბაზის სრული სარეზერვო ასლის შექმნა კრახით სრულდება და ლოგებში ერთადერთი ეს ჩანაწერი მხვდება:

There is insufficient system memory to run this query.

საქმე იმაშია, რომ სარეზერვო ასლის შექმნამდე, ეშვება Database Integrity Check–ი და შეცდომაც სწორედ მანდ ხდება, პროცესი ჩერდება და ასლი არ იქმნება. სარეზერვო ასლი სარეზერვო ასლად ცალკე საკითხია, მაგრამ ისიც გაითვალისწინეთ, რომ როგორც კი ეს შეცდომა ხდება, MS SQL სერვერი არამდგრად მუშაობას იწყებს და ძალიან არაადექვატურად იქცევა, იზრდება ტრანზაკციების რიცხვი, პრობლემები იქმნება CLR პროცედურებთან და ა.შ.  მოკლედ სანამ სერვერის რესტარტი არ მოხდება, აღარ შველის არაფერი…

პრობლემა პრობლემად გასაგებია და საინტერესო, მაგრამ როცა ეს ყველაფერი ნერვებთან ერთად მუშაობაშიც ხელს გიშლის,  უკვე აღარ გეღიმება. დავიწყე კვლევა–ძიება და ბევრი ქექვის მერე სასიკეთო მაინც ვერაფერი გავარკვიე სამწუხაროდ აღმოჩნდა, რომ კონკრეტული პირობების დაკმაყოფილების შემთხვევაში ეს შეცდომა ხდება და ვერც ვერაფრით ვერ ვშველით… (უფრო სწორედ ჯერ–ჯერობით ვერ ვუშველე, მუშაობა გრძელდება და შეგატყობინებთ შედეგებს )

მართალია ჯერ ვერაფრით დაგამშვიდეთ, მაგრამ იმას მაინც გეტყვით, რა “კონკრეტულ პირობებზე” მაქვს საუბარი

შეცდომა 701 საკმაოდ მრავალფეროვანია და სულ სხვადასხვა მომენტებში იჩენს თავს. ჩემი ძიების შედეგად აღმოვაჩინე, რომ ხდება ბაზის შემოწმებისას (DBCC CHECKDB), ტრანზაკციული ლოგის სარეზერვო ასლის შენახვისას, ბაზის სრული სარეზერვო ასლის შენახვისას, არაკორექტულად დაწერილი CLR პროცედურების გამოძახებისას და ასევე, როგორც ოფიციალურ HotFIX–შია ნათქვამი, (დიახ, დიახ, ასეთიც არსებობს, მაგრამ როგორც ჩანს მთლად კორექტულად არ მუშაობს)

In Microsoft SQL Server 2005, when you try to run several queries on large data sets at the same time, you may receive the following error message:
701: There is insufficient system memory to run this query.

ყველაფერთან ერთად, სერიოზული ეჭვი მაქვს, რომ ეს შეცდომა კიდევ ბევრ სხვა შემთხვევაშიც იჩენს თავს და თუ ცოტას მოინდომებთ და გუგული ბიძიას შეეკითხებით, მემგონი პასუხზეც არ დაგზარდებათ მივყვეთ თანმიმდევრობით. როგორც მე გავარკვიე, პრობლემა არის 32 ბიტიან ოპერაციულ სისტემებზე (არ აქვს მნიშვნელობა ფიზიკურად პროცესორი 32 თუ 64 ბიტიანია), სამართლიანია SQL Server 2005, SQL Server 2005 SP1 და SQL Server 2005 SP2–სათვის, როცა სერვერზე ჩართულია AWE-ს მხარდაჭერა. მოკლედ რომ ვთქვათ AWE წარმოადგენს მექანიზმს Windows-ში, რომელიც საშუალებას იძლევა 4 გიგაბაიტზე მეტი მეხსიერების დამისამართებისა. დეტალურად AWE–ს შესახებ შეგიძლიათ იხილოთ აქ. SQL 2005–ს აქვს საშუალება, რომ გამოიყენოს ოპერაციული სისტემის ეს მშვენიერი შესაძლებლობა და თავისი საჭიროებისათვის მოიხმაროს დიდი ზომის მეხსიერება (როგორც ფიზიკური, ისე ვირტუალური). ისიც უნდა გაითვალისწინოთ, რომ თუ ამ პარამეტრს ჩართავთ SQL სერვერზე, აუცილებელია, რომ მომხმარებელს, რომლის უფლებებითაც ეშვება SQL სერვერის ეკზემპლარი, ჰქონდეს უფლება Lock Pages in Memory. სხვა შემთხვევაში SQL სერვერი AWE–ს ვერ გამოიყენებს.(ინფორმაცია იმის შესახებ, თუ როგორ მივანიჭოთ მომხმარებელს ეს უფლება, იხილეთ აქ.)

სწორედ აქ იწყება მთავარი. SQL სერვერი ცდილობს დინამიურად გამოყოს/გაათავისუფლოს მეხსიერება საჭიროების მიხედვით. ჩვეულებრივ, SQL სერვერს პარამეტრებში მითითებული აქვს მინიმალური ზომა რომელიც უნდა გამოყოს (1GB) ხოლო მაქსიმალური მეხსიერება, რომელიც მითითებულია, იმდენად დიდია (2048TB :)) რომ გინდ ეგ ყოფილა და გინდ ულიმიტო ანუ სერვერი საჭიროების შემთხვევაში ეცდება მთლიანად დაიკავოს არსებული მეხსიერება. Bug–იც აქ იჩენს თავს. გაუგებარი მიზეზებით, SQL სერვერი გადის მეხსიერების დასაშვები  საზღვრებიდან და ცდილობს დაიკავოს იმაზე მეტი, ვიდრე ფიზიკურად ან ვირტუალურადაა გამოყოფილი კომპიუტერზე, ხდება შეცდომა და ყველაფერი თავზე გვექცევა.

თუ Microsoft–ს დავუჯერებთ, როგორც ზემოთ ნახსენებ HotFix–შია ნათქვამი, შეცდომა 701 გამოსწორებულია ჯერ კიდევ SQL Server 2005 SP 1–ში, მაგრამ როგორც მივხვი, ამ შეცდომის კონკრეტული გამოვლინებაა გამოსწორებული და არა ის, რაც ჩემს შემთხვევაში იჩენს თავს. უამრავი საინტერესო ლინკი ვიპოვე სხვადასხვა ფორუმებზე თუ ბლოგებზე, მაგრამ რეალურ გადაწყვეტილებას ვერსად მივაგენი. ვნახე ერთი ზუსტად ჩემი ტიპის შეცდომაც: როგორც ჩემს შემთხვევაში, იქაც საუბარია რამდენიმე ათეულ გიგაბაიტიან ბაზაზე, რომელზეც DBCC CHECKDB კრახით სრულდება და ლოგში შეცდომა 701 ფიქსირდება. იქაც გამოსავალი ჯერ ვერ იპოვნეს

ძირითადი რეკომენდაციები Trace Flag–ებით სერვერის გაშვებაზე და მეხსიერების მიმდინარე მდგომარეობის Microsoft–ისათვის გადაგზავნით შემოიფარგლება თუმცა არის Pinal Dave–ს საინტერესო ბლოგი რომელზეც ავტორი Min და Max Server Memory პარამეტრების მნიშვნელობებით ექსპერიმენტირებას გვთავაზობს. სამართლიანობა მოითხოვს აღინიშნოს, რომ ჯერ ეგ არ მიცდია, მაგრამ იგივე სამართლიანობა მოითხოვს აღინიშნოს, რომ ანალოგიური წარმატებით ამტკიცებენ სხვა ბლოგებსა და ფორუმებზე, რომ არც მაგ პარამეტრებით ექსპერიმენტირება შველის საქმეს…

“აბა რა ვქნათ? არ არის საშველი?” მკითხავთ თქვენ. საშველი არის, მაგრამ ყოველთვის მარტივად ვერ განახორციელებთ მიგრაცია 64 ბიტიან ოპერაციულ სისტემაზე

მოკლედ საკმაოდ პესიმისტური პოსტი გამომივიდა, მაგრამ ფაქტი ჯიუტია და თან მუშაობაშიც ხელს გვიშლის, ამიტომ ვიფიქრე ჩემი რამდენიმე დღიანი კვლევა–ძიების შედეგები მოკლედ დამედო ბლოგზე, რომ მომავალში ჩემნაირ გაჭირვებულებს არ დაჭირდეთ 2–3 დღის დახარჯვა იმის გასარკვევად, რომ ამ ეტაპზე პრობლემა მოგვარებას არ ექვემდებარება.

P.S. როგორც ყოველთვის სიამოვნებით მოვისმენ თქვენს შენიშვნებს და გავიზიარებ გამოცდილებას ამ საკითხთან დაკავშირებით. ასევე პირობას ვდებ, რომ ნებისმიერი ახალი ინფორმაციის მოპოვების შემთხვევაში აუცილებლად ჩაგაყენებთ საქმის კურსში

P.P.S.  მცირე ექსპერიმენტების შედეგად ნაპოვნია გამოსავალი