ჩვენ გადავედით ახალი სერვერი. მასზე SQL და 1C. ძველებთან შედარებით ბევრად მაგარი იყო. გილევის ტესტმაც დაადასტურა ეს: ძველ სერვერებზე 10-15-ის წინააღმდეგ გამოსცა 39. ამიტომ, შეძენისთანავე გადავიტანეთ მონაცემთა ბაზა და დავიწყეთ მუშაობა.

მაგრამ რაღაც მომენტში, რაღაც არასწორედ მოხდა - მომხმარებლებმა დაიწყეს ჩივილი ნელი მუშაობა. ჩვენ დავაყენეთ გარკვეული პარამეტრები სერვერისა და სერვისებისთვის (რომლებიც ცალკე პოსტის თემაა) და გადავწყვიტეთ სერვერის გადატვირთვა, რადგან გადატვირთვის სიჩქარე იყო 2 წუთი (სხვა სერვერებზე 10-ს მიაღწია). ამის შემდეგ, 1C შესვლისას, ვიღებთ შემდეგ შეტყობინებას:

"ყურადღება!!! მონაცემების განახლებისას, შემდეგ ბოლო რესტრუქტურიზაცია, მოხდა შეცდომა. ხელახლა სცადოთ განახლება?" "Ნამდვილად არ"

"დიახ" ღილაკზე დაჭერის შემდეგ გამოჩნდება შემდეგი:

"გამოვლინდა არასრული კონფიგურაციის შენახვის ოპერაცია. ოპერაციის გასაგრძელებლად უნდა დაასრულოთ“.

პირველი რაც გადავწყვიტე იყო CHECKDB Managment Studio-ში - 2 საათის ლოდინის შემდეგ (500 GB მონაცემთა ბაზა) - ყველაფერი რიგზეა.

ქსელის უზარმაზარ ნაწილში აღმოვაჩინე ინფორმაცია, რომ იგივე შეცდომა ხდება დინამიური განახლებების დროს.

ქსელში შემოთავაზებული გადაწყვეტილებები მაშინვე არ დაეხმარა, მაგრამ სხვა ქმედებებთან ერთად მათ შედეგი გამოიღო. მაშ რა გავაკეთე:

გამოსავალი:

1. რა აკლდა გადაწყვეტილებებს ქსელიდან:

sp_configure 'განახლების დაშვება', 1
ხელახლა კონფიგურაცია გადაფარვით
წადი

2. მონაცემთა ბაზის აღდგენის რეჟიმში გადატანა

შეცვალოს მონაცემთა ბაზის ნაკრები EMERGENCY, SINGLE_USER

3. ჩვენ ვასრულებთ მონაცემთა ბაზის ტესტირებას:

dbcc checkdb('db_name', REPAIR_ALLOW_DATA_LOSS)

4. ჩვენ გამოვიყვანთ მონაცემთა ბაზას აღდგენის რეჟიმიდან:

მონაცემთა ბაზის შეცვლა ONLINE, MULTI_USER

5. პრინციპში, თუ დარწმუნებული ხართ, რომ თავად ბაზაზე ყველაფერი წესრიგშია, მაშინ 2-4 ქულას ვერ გააკეთებთ. შემდეგი, ჩვენ ვასრულებთ ორ მოთხოვნას SQL პროფილში:

წაშალეთ კონფიგურაციიდან, სადაც FileName = 'commit'
წაშალეთ კონფიგურაციიდან, სადაც FileName = 'dbStruFinal'

ეს ჩანაწერები პასუხისმგებელია დინამიურ განახლებაზე - არ შეგეშინდეთ მათი წაშლა.

მონაცემთა ბაზების სამუშაო ვერსიებში, შეკითხვებს:

აირჩიეთ * Config-დან WHERE FileName = 'commit'

აირჩიეთ * კონფიგურაციიდან WHERE FileName = 'dbStruFinal'

ცარიელი იქნება.

6. დააბრუნეთ პარამეტრები:

sp_configure 'განახლების დაშვება', 0
წადი

7. ამის შემდეგ მოვახერხეთ კონფიგურატორის გაშვება და მონაცემთა ბაზამ დაიწყო მუშაობა.

ასევე, ბაზას შეუძლია იმუშაოს პირველი დროშის მოხსნის შემდეგ.

Sandbox

ავტორიტეტი 2013 წლის 18 სექტემბერი, 03:24 სთ

1C, კონფიგურაციის აღდგენა საინფორმაციო ბაზა MS SQL-ის გამოყენებით

ერთ დროს შემექმნა პრობლემა: კონფიგურაციის საცავიდან განახლებისას მოხდა მარცხი და 1C დაიხურა.

როგორც მოგვიანებით გაირკვა, კონფიგურაციის საცავი განადგურდა და როდესაც კონფიგურაცია განახლდა, ​​მონაცემთა ბაზის კონფიგურაციაც გაფრინდა საცავიდან. მსგავსი შეცდომა ადრეც მოხდა IB-ის დინამიური განახლებით.

იმიტომ რომ ეს პრობლემაგაჩნდა არაერთხელ გადაწყვიტა მკურნალობის ვარიანტის გაზიარება.

შემდეგ ჯერზე, როცა კონფიგურატორი გაუშვით, მოხდა შეცდომა: „ყურადღება!!! ბოლო რესტრუქტურიზაციის შემდეგ მონაცემების განახლებისას მოხდა შეცდომა. ხელახლა სცადოთ განახლება?" თუ პასუხი დადებითია, ჩვენ ვიღებთ შეტყობინებას: „აღმოჩენილია არასრული კონფიგურაციის შენახვის ოპერაცია. მუშაობის გასაგრძელებლად, თქვენ უნდა დაასრულოთ ოპერაცია ”შემდეგ აპლიკაცია იხურება.

ამ პრობლემის გაანალიზებისას იპოვეს პრობლემის რამდენიმე გამოსავალი, თითოეული გამოსავალი მუშაობს სხვადასხვა შემთხვევაში.

ვარიანტი 1 (თუ გაქვთ SQL სარეზერვო ასლი იდენტური კონფიგურაციით):

განლაგებულია IB-ის ასლი და მოთხოვნილია შემდეგი კონსტრუქცია:
გამოიყენეთ GO DELETE FROM .. GO INSERT INTO .. ​​SELECT * FROM .. GO
ამავდროულად, ცხრილი, რომელშიც ინახება IS კონფიგურაცია, ხელახლა ივსება. მიზანშეწონილია ჩაატაროთ IS ტესტირება და კორექტირება ამ ოპერაციის შემდეგ.

ვარიანტი 2 (თუ არ არის სარეზერვო):

ეს ვარიანტი განიხილებოდა, როგორც ბოლო წვეთი. იმიტომ რომ კონფიგურაცია დამუშავების პროცესში იყო და მათ ცოტათი დაივიწყეს სარეზერვო ასლი, საცავზე დაყრდნობით.
მონაცემთა ბაზაში ორი ჩანაწერი იშლება "Config" ცხრილიდან "FileName" სვეტის მნიშვნელობით - dbStruFinal და commit

შესრულებულია შემდეგი მოთხოვნა:
გამოიყენეთ GO DELETE FROM. WHERE FileName = "dbStruFinal" GO DELETE FROM. WHERE FileName = "commit" GO
უცნაურად საკმარისია, რომ ბაზა ცოცხლდება.

ტეგები: 1s enterprise 8.2, SQL, კონფიგურაციის აღდგენა

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

1C:Enterprise-ში მუშაობისას შეიძლება გამოჩნდეს შემდეგი შეტყობინება: „თან მუშაობა ახალი ვერსია 1C: საწარმო, ინფო ბაზა უნდა გადაკეთდეს. რატომ ჩნდება ეს ფანჯარა და როგორ გამოვასწორო შეცდომა?

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

DB კონვერტაცია

ეს პროცედურა მარტივია, თუმცა რეკომენდებულია ჯერ შექმნა სარეზერვობაზა, თუ კონვერტაციის დროს მოხდა შეცდომა (მაგალითად, კომპიუტერი გამორთულია, შედეგად საინფორმაციო ბაზა 1C, ისევე როგორც თავად პროგრამა, შეიძლება დაზიანდეს). შემდეგ გამოიყენეთ მოქმედებების შემდეგი ალგორითმი:

• გახსენით მონაცემთა ბაზა კონფიგურატორის რეჟიმში;
• თქვენ იხილავთ შეტყობინებას, რომელიც მოგთხოვთ ინფორმაციის ბაზის კონვერტაციას. პრესის დადასტურება;

• დახურეთ კონფიგურატორი.

გახსენით მონაცემთა ბაზა - ის უნდა დაიწყოს უპრობლემოდ. თუ შეცდომის ფანჯარა კვლავ გამოჩნდება კონვერტაციის შემდეგ, შეგიძლიათ სცადოთ პროცედურა ხელახლა. იმ შემთხვევაში, როდესაც ეს არ დაეხმარება, თქვენ უნდა დაუკავშირდეთ 1C პროგრამისტს. ზოგჯერ პროგრამა შეიძლება გაიყინოს ოპერაციის შესრულებისას. ამ დროს არანაირი ქმედება არ არის საჭირო.

Მნიშვნელოვანი! საინფორმაციო ბაზა 1C, გარდაიქმნა უახლესი ვერსიაპროგრამების გახსნა წინა ვერსიებზე შეუძლებელია.

ფონი

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

აქ ყველაფერი ნათელია. ჩანაწერები გახდა არაუნიკალური, თქვენ უნდა წაშალოთ ისინი!

უმარტივესი გზაა:

NewRecord =RegistersInfo.MessageTrackingLog.CreateRecordSet(); NewRecord.Record();

ამ მეთოდით ჩვენ ძალიან სწრაფად გავასუფთავებთ რეესტრს 1C-ში (მაგრამ ესეც ჩვენი შეცდომა იქნება).

შეცდომა

როგორც ჩანს, რეესტრი ცარიელია და შეგიძლიათ განაახლოთ 1C. არ მინდა გაგიკვირდეთ, მაგრამ ისევ იქნება შეცდომა:

რა არის შეცდომა:

საინფორმაციო ბაზის განახლებისას მოხდა კრიტიკული შეცდომა
გამო:
არაუნიკალური მნიშვნელობის უნიკალურ ინდექსში ჩასმის მცდელობა:
მაიკროსოფტი SQL სერვერი Native Client 11.0: CREATE UNIQUE INDEX განაცხადი შეწყდა, რადგან ნაპოვნი იქნა დუბლიკატი გასაღები ობიექტის სახელისთვის "dbo._InfoRgChngR34546NG" და ინდექსის სახელი "_InfoR34546_ByNodeMsg_RNTSRRRRRRNG". გასაღების დუბლიკატი მნიშვნელობა არის (0x00000011,d7, , სექ 27 4015 10:22PM, 768404.00.00.00.00.00.00).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, მდგომარეობა=1, სიმძიმე=10, მშობლიური=1505, ხაზი=1

ახსნა

მოდით გავიგოთ SQL სტრუქტურა. ჩვენ გვაქვს რეესტრი "MessageTrackingLog", SQL-ში ის არის ცხრილში " _InfoR34546". ამის შემოწმება შეგიძლიათ სპეციალური დამუშავებით ან "poke" მეთოდით (ეს არ უნდა გავაკეთოთ, რადგან ცხრილის სახელი უკვე მითითებულია შეცდომის ტექსტში).

ახლა აგიხსნით რა მოხდა. როდესაც ჩვენ ჩავტვირთეთ მონაცემები რეესტრში, შემდეგ SQL-ში ისინი მოხვდნენ ცხრილში " _InfoR34546". როდესაც ჩვენ გავასუფთავეთ ცხრილი 1C კოდით, ეს მონაცემები წაიშალა ცხრილიდან " _InfoR34546", მაგრამ ისინი დაკოპირდა ცხრილში " _InfoRgChngR34546". ეს გახდა პრობლემა.

გამოსავალი

პრობლემის გადასაჭრელად, ჩვენ უნდა გავასუფთავოთ SQL ცხრილი "_InfoRgChngR34546".

„Microsoft SQL Server Management Studio“-ს მაგალითზე გეტყვით. Ჩვენ მივდივართ " მენეჯმენტის სტუდია". ჩვენ ვპოულობთ ჩვენს მონაცემთა ბაზას, ვხსნით ცხრილების ჩანართს, ვაწკაპუნებთ ნებისმიერზე და ვაჭერთ ღილაკს "ახალი შეკითხვა": ახლა ვწერთ შეკითხვას.

ცხრილის შეკვეცა "_InfoRgChngR34546"

შეგიძლია სხვა მაგიდაც გქონდეს! Არ დაგავიწყდეს!

და დააჭირეთ Run ან F5. აი რა უნდა იყოს შედეგი:

ყველაფერი, ახლა შეგიძლიათ უსაფრთხოდ განაახლოთ 1C და არ იქნება შეცდომა!