Переїжджали ми на новий сервер. На ньому SQL і 1C. У порівнянні зі старими був набагато крутіше. І тест Гильова це теж підтвердив: проти 10-15 на старих серверах видавав 39. Тому ми відразу після покупки перенесли базу і почали роботу.
Але в якийсь момент щось пішло не так - користувачі стали скаржитися на повільну роботу. Зробили певні настройки сервера і служб (які - тема окремого поста) і вирішили перезавантажити сервер, благо швидкість перезавантаження - 2 хвилини (на інших серверах до 10 доходило). Після цього при вході в 1С отримуємо наступне повідомлення:
"Увага!!! При оновленні даних, після останньої реструктуризації, сталася помилка. Повторити оновлення? » "Та ні"
Після натискання кнопки «Так» з'являється наступне:
«Виявлена \u200b\u200bнезавершена операція збереження конфігурації. Для продовження роботи необхідно завершити операцію. »
Перше, що вирішив зробити - CHECKDB на в Managment Studio - після 2х годин очікування (база 500 ГБ) - все ОК.
На просторах мережі знайшов інформацію, що така ж помилка буває при динамічному оновленні.
Рішення, запропоновані в мережі відразу не допомогли, але вкупі з іншими дії дали результат. Отже, що я робив:
Рішення:
- Те, чого не вистачало для рішень з мережі:
sp_configure 'allow updates', 1
reconfigure with override
go
2. Переводимо базу в режим відновлення
alter database set EMERGENCY, SINGLE_USER
3. Виконуємо тестування бази:
dbcc checkdb ( 'db_name', REPAIR_ALLOW_DATA_LOSS)
4. Виводимо базу з режиму відновлення:
alter database set ONLINE, MULTI_USER
5. В принципі, якщо впевнені що з самої базою все ок, то можна не робити 2-4 пункти. Далі виконуємо два запити в профайлером SQL:
delete from config where FileName \u003d 'commit'
delete from config where FileName \u003d 'dbStruFinal'Ці записи і відповідають за динамічне оновлення - можна не боятися їх видаляти.
У робочих версіях баз запити:
select * from Config WHERE FileName \u003d 'commit'
select * from Config WHERE FileName \u003d 'dbStruFinal'
будуть порожні.
6. повертаємо настройки:
sp_configure 'allow updates', 0
go
7. Після цього вдалося запустити конфігуратор і спортивна база почала працювати.
Також база може заробити після видалення першого прапора.
Пісочниця
авторитет 18 вересня 2013 о 15:241С, відновлення конфігурації інформаційної бази з використанням MS SQL
Свого часу зіткнувся з проблемою: при оновленні конфігурації зі сховища, стався збій, і закрилася 1С.
Як з'ясувалося пізніше - сталося руйнування сховища конфігурації та при оновленні конфігурації зі сховища злетіла і конфігурація БД. Подібна помилка виникала перш за динамічне оновлення ІБ.
Оскільки дана проблема виникала неодноразово вирішив поділиться варіантом лікування.
При наступному запуску конфігуратора вийшла помилка: «Увага !!! При оновленні даних, після останньої реструктуризації, сталася помилка. Повторити оновлення? » при позитивному відповіді отримуємо повідомлення: «Виявлена \u200b\u200bнезавершена операція збереження конфігурації. Для продовження роботи необхідно завершити операцію »після цього додаток закривається.
При розборі даної проблеми було знайдено кілька варіантів вирішення проблеми, кожне рішення працює в різних випадках.
Варіант 1 (при наявності бекапа SQL c копією з ідентичною конфігурацією):
Розгортається копія ІБ, і виконується запит на введення такої конструкції:
USE GO DELETE FROM .. GO INSERT INTO .. \u200b\u200bSELECT * FROM .. GO
При цьому пере заливається таблиця в якій зберігається конфігурація ІБ. Бажано після даної операції виконати тестування і виправлення ІБ.
Варіант 2 (при відсутності бекапа):
До цього виду звернулися як до останньої соломинки. Оскільки конфігурація була в стадії розробки і про бекап трохи забули сподіватимемося на сховище.
У базі видаляються два записи з таблиці «Config» за значенням в стовпці «FileName» - dbStruFinal і commit
Виконується наступний запит:
USE GO DELETE FROM. WHERE FileName \u003d "dbStruFinal" GO DELETE FROM. WHERE FileName \u003d "commit" GO
Як не дивно база оживає.
Теги: 1с підприємство 8.2, SQL, відновлення конфігурації
Дана стаття не підлягає коментування, оскільки її автор ще не є повноправним учасником спільноти. Ви зможете зв'язатися з автором тільки після того, як він отримає
Передісторія
Потрібно нам було створити новий реєстр відомостей "ЖурналОтслежіваніяСообщеній". Додали в конфігурацію, завантажили дані. Потім пішла робота по оптимізації. Довелося міняти структуру регістра. Але не тут-то було!
Тут все ясно. Записи стали неунікальні, потрібно їх видалити!
Найпростішою спосіб це:
НоваяЗапісь \u003d РегістриСведеній.ЖурналОтслежіваніяСообщеній.СоздатьНаборЗапісей (); НоваяЗапісь.Запісать ();
Таким методом ми очистимо регістр в 1С дуже швидко (але це буде і нашою помилкою).
Помилка
Здавалося б, в регістрі порожньо, і можна оновлювати 1С. Не хочу вас здивувати, але буде знову помилка:
Що ж являє помилка:
У процесі оновлення інформаційної бази сталася критична помилка
по причині:
Спроба вставки неунікального значення в унікальний індекс:
Microsoft SQL Server Native Client 11.0: The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name "dbo._InfoRgChngR34546NG" and the index name "_InfoR34546_ByNodeMsg_RNTSRRRRRRNG". The duplicate key value is (0x00000011, d7,, Sep 27 4015 10:22 PM, 768404,00,00,00,00,00,00).
HRESULT \u003d 80040E2F, SQLSrvr: SQLSTATE \u003d 23000, state \u003d 1, Severity \u003d 10, native \u003d 1505, line \u003d 1
пояснення
Давайте розберемося зі структурою SQL. У нас є регістр "ЖурналОтслежіваніяСообщеній", він в SQL знаходиться в таблиці " _InfoR34546 ". Перевірити це ви можете спеціальними обробками або методом" тику "(нам це не доведеться робити тому що в тексті помилки вже зазначено назву таблиці).
А тепер поясню, що ж сталося. Коли ми завантажили дані в регістр, то в SQL вони потрапили в таблицю " _InfoR34546 ". Коли ми кодом в 1С очистили таблицю, то ці дані пішли з таблиці" _InfoR34546 ", але вони скопіювали в таблицю" _InfoRgChngR34546 ". Це і стало проблемою.
Рішення
Для вирішення виниклої проблеми нам знадобиться очистити SQL таблицю "_InfoRgChngR34546".
Розповім на прикладі "Microsoft SQL Server Management Studio". Заходимо в " Management Studio ". Знаходимо нашу базу, відкриваємо вкладку таблиць, натискаємо на будь-яку і тиснемо кнопку" Новий запит ":. Тепер набираємо запит
Truncate table "_InfoRgChngR34546"
У вас може бути і інша таблиця! Не забувайте!
І тиснемо виконати або клавішу "F5". Ось такий повинен бути результат:
Все, тепер можна спокійно оновлювати 1С, і помилки не буде!
