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

როგორც ჩემს წინა პოსტში ვწერდი, SQL 2005–ზე, თუ ის 32 ბიტიან სისტემაზე დგას და გააქტიურებული აქვს AWE, კონკრეტულ მომენტებში საკმაოდ უსიამოვნო შეცდომა იჩენს თავს და ამ დროისათვის პირდაპირი FIX არ არსებობს. იქვე ავღნიშნე, რომ Pinal Dave–ს ბლოგზე გამოსავალის სახით Max Server Memory–ს ხელით მითითება იყო შემოთავაზებული.

ბევრი რომ აღარ გავაგრძელო, Max Server Memory–ს პარამეტრთან ექსპერიმენტირებამ დადებითი შედეგი მოიტანა პრობლემა, რომელიც მე მექმნებოდა და რის გამოც Error 701 ხდებოდა, ლოკალიზებულია. ჩემს შემთხვევაში, როცა სერვერზე X გიგაბაიტი მეხსიერებაა, Max Server Memory–ში X-1გიგაბაიტის მითითებით მოხერხდა პრობლემის აღმოფხვრა. რატომ X-1 და არა X გიგაბაიტი? საქმე იმაშია, რომ ასევე არსებობს რეკომენდაცია, რომ ხელით გაწერისას რაღაც რეზერვი მეხსიერებისა, დარჩეს ოპერაციული სისტემისათვის, რომ უცებ არ აღმოჩნდეს რომ SQL მუშაობს, მაგრამ ოპერაციულ სისტემას მეხსიერება აღარ ჰყოფნის.

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

მოკლედ რომ ვთქვათ, ჩემი მწარე გამოცდილებიდან გამომდინარე, პრაქტიკულად დარწმუნებული ვარ, რომ  არსებობს რაღაც პრობლემა Memory Management–ში, რომელიც 32 ბიტიან სისტემაზე, 4 გიგაბაიტზე მეტი მეხსიერებისას და გააქტიურებული AWE–სას იჩენს თავს და თან სულ სხვადასხვა სახით. თუ არსებულმა Hot Fix–ებმა ვერაფერი ხეირი ვერ მოგიტანათ, ცადეთ Max Memory პარამეტრის ცხადად განსაზღვრა. შანსი იმისა, რომ გეშველოთ, როგორც ჩანს საკმაოდ დიდია

P.S. დიდი მადლობა Pinal Dave–ს