ჩვენ გადავედით ახალ სერვერზე. მასზე SQL და 1c. შედარებით ძველი იყო გაცილებით ქულერი. და გამოცდა გალიას ასევე დაადასტურა: 10-15 წლამდე ძველი სერვერების წინააღმდეგ 39. ამიტომ, ჩვენ დაუყოვნებლივ გადავწყვიტეთ ბაზა და მუშაობა დაიწყო.
მაგრამ რაღაც მომენტში რაღაც არასწორი იყო - მომხმარებლებმა დაიწყეს საჩივარი ნელი მუშაობის შესახებ. მათ წარმოადგინეს გარკვეული სერვერის პარამეტრები და მომსახურება (რაც ცალკე პოსტის საგანი) და სერვერის გადატვირთვა გადაწყვიტა, გადატვირთვის მაჩვენებლის სასარგებლოდ არის 2 წუთი (მიაღწია 10 სერვერს). ამის შემდეგ, როდესაც შესვლისას 1C, ჩვენ მივიღებთ შემდეგ შეტყობინებას:
"ყურადღება! მონაცემების განახლებისას, ბოლო რესტრუქტურიზაციის შემდეგ, შეცდომა მოხდა. განმეორებითი განახლება? " "კარგად არა"
"დიახ" ღილაკზე დაჭერით, შემდეგ გამოჩნდება:
"აღმოაჩინეს დაუმთავრებელი კონფიგურაციის კონსერვაციის ოპერაცია. გააგრძელეთ მუშაობა, თქვენ უნდა შეავსოთ ოპერაცია. "
პირველი, რაც მე გადავწყვიტე, არის Checkdb- ის მენეჯმენტის სტუდიაში - 2 საათის შემდეგ (500 GB ბაზა) - ყველაფერი კარგად არის.
ქსელში ქსელში აღმოაჩინეს ინფორმაცია, რომ იგივე შეცდომა ხდება, როდესაც დინამიურად განახლდება.
ქსელში შემოთავაზებული გადაწყვეტილებები არ დაეხმარა, მაგრამ სხვა ქმედებებთან იყო შედეგი. ასე რომ, რაც მე გავაკეთე:
გადაწყვეტილება:
- რა იყო დაკარგული გადაწყვეტილებების ქსელიდან:
sP_Configure 'Allo განახლებები', 1
Reconfigure ერთად override.
გადასვლა.
2. მონაცემთა ბაზის გადარიცხვა აღდგენის რეჟიმში
ალტერნატიული მონაცემთა ბაზის მოწყობა, Single_User
3. ბაზის ტესტირება:
dBCC Checkdb ('db_name', repair_allow_data_loss)
4. მონაცემთა ბაზის აღდგენა აღდგენის რეჟიმში:
ალტერნატიული მონაცემთა ბაზა Set Online, Multi_user
5. პრინციპში, თუ დარწმუნებული ხართ, რომ ყველაფერი კარგადაა, მაშინ 2-4 ქულა არ შეგიძლია. შემდეგი, ჩვენ ვასრულებთ ორ მოთხოვნას SQL Profiler- ში:
წაშალეთ კონფიგურაცია, სადაც FileNAME \u003d 'ვალდებულებას'
წაშალეთ კონფიგურაცია, სადაც filename \u003d 'dbstrufinal'ეს ჩანაწერები პასუხისმგებელნი არიან დინამიური განახლებისთვის - ვერ გეშინია მათ წაშლა.
მონაცემთა ბაზების სამუშაო ვერსიებში ითხოვს:
აირჩიეთ * CONFIG- ისგან, სადაც FILENAME \u003d 'ვალდებულებას'
აირჩიეთ * CONFIG- დან, სადაც FILENAME \u003d 'DBSTRUFINAL'
ცარიელი იქნება.
6. დაბრუნების პარამეტრები:
sP_Configure 'დაუშვას განახლებები', 0
გადასვლა.
7. ამის შემდეგ, შესაძლებელი იყო კონფიგურატორის დაწყება და ბაზა.
ასევე, ბაზა შეიძლება მიიღოთ პირველი დროშის მოხსნის შემდეგ.
სავარჯიშო
ავტორიტეტი 2013 წლის 18 სექტემბერს 15:24 საათზე1C, საინფორმაციო ბაზის კონფიგურაციის აღდგენა MS SQL- ის გამოყენებით
ერთ დროს, პრობლემა შევიდა: საცავიდან კონფიგურაციის განახლებისას, მარცხი მოხდა და 1C დაიხურა.
მოგვიანებით აღმოჩნდა, კონფიგურაციის საცავი განადგურდა და მონაცემთა ბაზის კონფიგურაცია შენახული კონფიგურაციისგან გადაიდო. ასეთი შეცდომა მოხდა IB- ის განახლებისას.
იმიტომ რომ ეს პრობლემა არ არის გადაწყდა მკურნალობის პარამეტრის გაზიარება.
მომდევნო დროს კონფიგურატორი იწყებს შეცდომას: "ყურადღება! მონაცემების განახლებისას, ბოლო რესტრუქტურიზაციის შემდეგ, შეცდომა მოხდა. განმეორებითი განახლება? " დადებითი რეაგირებით, ჩვენ მივიღებთ შეტყობინებას: "დაუმთავრებელი კონფიგურაციის შენახვის ოპერაცია გამოვლინდა. გააგრძელეთ მუშაობა, ოპერაცია უნდა შეავსოთ ". ამის შემდეგ, განაცხადის დახურვა.
ამ პრობლემის ანალიზით, რამდენიმე გადაწყვეტა აღმოჩნდა, თითოეული გამოსავალი სხვადასხვა საქმეებში მუშაობს.
ვარიანტი 1 (თუ არსებობს SQL სარეზერვო ასლი იდენტური კონფიგურაციით):
IB- ის ასლი განლაგებულია და შემდეგი დიზაინი კონფიგურირებულია:
გამოიყენეთ წაშლა .. წავიდეთ ჩასმა .. აირჩიეთ * .. წადი
ამავდროულად, მაგიდა, რომელშიც IB კონფიგურაცია ინახება. სასურველია ამ ოპერაციის შემდეგ, შეასრულოს IB ტესტირება და კორექტირება.
ვარიანტი 2 (სარეზერვო არარსებობის შემთხვევაში):
ეს ვარიანტი ითხოვდა ბოლო ჩალის. იმიტომ რომ კონფიგურაცია იყო განვითარების ეტაპზე და სარეზერვო შესახებ საცავში იმედით.
"Config" ცხრილისგან ორი ჩანაწერი წაიშლება "ფაილის სახელიდან" - DBSTRufinal და ჩაიდინოს
შესრულებულია შემდეგი შეკითხვა:
გამოიყენეთ წაშლა წაშლა. სადაც filename \u003d "dbstrufinal" წაშლა წაშლა. სადაც filename \u003d "ჩაიდინოს" წასვლა
უცნაური საკმარისი ბაზა მოდის ცხოვრებაში.
Tags: 1C საწარმო 8.2, SQL, კონფიგურაციის აღდგენა
ეს სტატია არ ექვემდებარება კომენტარს, რადგან მისი ავტორი ჯერ კიდევ არ არის საზოგადოების სრული წევრი. თქვენ შეგიძლიათ დაუკავშირდეთ ავტორი მხოლოდ მას შემდეგ, რაც იგი იღებს
წინაშია
ჩვენ გვჭირდებოდა "ჟურნალისტის" ინფორმაციის ახალი რეესტრის შექმნა. დაემატა კონფიგურაცია, გადმოწერილი მონაცემები. შემდეგ წავიდა ოპტიმიზაცია. რეესტრის სტრუქტურის შეცვლა მქონდა. მაგრამ ეს არ იყო იქ!
აქ ყველაფერი ნათელია. ჩანაწერები დაუსაბუთებელი გახდა, თქვენ უნდა ამოიღონ ისინი!
უმარტივესი გზაა:
Novaya რეგისტრაცია \u003d რეგისტრაცია. სავალდებულოა. მოთხოვნის შექმნა (); ახალი რეგისტრაცია. დასრულება ();
ამდენად, ჩვენ გაწმენდის რეესტრს 1C ძალიან სწრაფად (მაგრამ ეს იქნება ჩვენი შეცდომა).
შეცდომა
როგორც ჩანს, რეესტრი ცარიელია, და თქვენ შეგიძლიათ განაახლოთ 1C. მე არ მინდა გაოცება, მაგრამ შეცდომა კიდევ ერთხელ იქნება:
რა არის შეცდომა:
საინფორმაციო ბაზის განახლების პროცესში, კრიტიკული შეცდომა მოხდა.
იმის გამო, რომ:
უნიკალური ღირებულების ჩასმა უნიკალური ინდექსის ჩასმა:
Microsoft SQL Server მშობლიური კლიენტი 11.0: შექმნა უნიკალური ინდექსი განაცხადი შეწყვიტა, რადგან დუბლიკატი გასაღები აღმოჩნდა ობიექტის სახელი "DBO._inforgchngr3454546ng" და ინდექსი სახელი "_infor34546_bynodemsg_rntsrrrrrng". დუბლიკატი ძირითადი მნიშვნელობა არის (0x00000011, D7,, სექტემბერი 27 4015 10:22 PM, 768404.00.00.00.00.00.00.00.00).
HRESULT \u003d 80040E2F, SQLSRVR: SQLSTATE \u003d 23000, STATE \u003d 1, სიმძიმის \u003d 10, მშობლიური \u003d 1505, line \u003d 1
ახსნა
მოდით გაერკვნენ ის SQL სტრუქტურასთან. ჩვენ გვაქვს რეგისტრაცია "ჟურნალის კოსობა", ეს არის SQL მაგიდაზე " _Infor34546 ". შეამოწმეთ იგი. თქვენ შეგიძლიათ სპეციალური დამუშავება ან" Tyk "მეთოდი (ჩვენ არ უნდა გავაკეთოთ ეს. შეცდომის ტექსტში, მაგიდა უკვე მითითებულია).
ახლა მე ავუხსენი, რა მოხდა. როდესაც ჩვენ გადმოწერილი მონაცემები რეესტრში, მაშინ SQL მათ მაგიდაზე " _Infor34546 ". როდესაც ჩვენ 1C- ში მაგიდაზე გაწმენდილი, მაშინ ეს მონაცემები ამოღებულ იქნა მაგიდაზე" _Infor34546 ", მაგრამ ისინი გადაწერეს მაგიდასთან" _Inforgchngr34546 ". ეს პრობლემა გახდა.
გადაწყვეტილება
პრობლემის მოსაგვარებლად, საჭიროა SQL ცხრილის გასუფთავება "_inforgchngr34546".
მე გეტყვით "Microsoft SQL Server Management Studio" მაგალითზე. Წადი " მენეჯმენტის სტუდია. ჩვენ ვიპოვით ჩვენს მონაცემთა ბაზას, გახსენით მაგიდები tab, დააწკაპუნეთ ნებისმიერ და დააჭირეთ "ახალი მოთხოვნის" ღილაკს :. ახლა გააქტიურეთ მოთხოვნა
Truncate მაგიდა "_inforgchngr34546"
თქვენ შეიძლება კიდევ ერთი მაგიდა! Არ დაგავიწყდეს!
და დააჭირეთ ასრულებს ან "F5". აქ არის ასეთი შედეგი:
ყველა, ახლა თქვენ შეგიძლიათ უსაფრთხოდ განახლება 1C, და არ იქნება შეცდომები!
