1с ремонт таблицы sql

Содержание

Восстановление работоспособности SQL базы «1С предприятие 8» после падения во время обновления
Проверка базы данных 1C на целостность и исправление ошибок MS SQL.
Восстановление базы 1С под SQL-Server

Восстановление работоспособности SQL базы «1С предприятие 8» после падения во время обновления

Приветствую Вас, дорогие читатели.

Совсем недавно мне пришлось восстанавливать базу «1С предприятие 8» после падения, которое произошло во время обновления конфигурации. Причем это было дважды и методы примененные при восстановлении тоже были разными (скоро узнаете почему). В данной статье я хочу рассказать о тех способах, которыми я воспользовался.

Все способы рассматриваемые в статье относятся к серверному варианту работу «1С предприятие 8», используемое СУБД — MS SQL 2005.

Случай №1.

При обновлении конфигурации была выдана ошибка «Конфликт блокировок», конфигуратор был закрыт. При повторной попытке входа в конфигуратор появилась ошибка: Внимание. При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»

При положительном ответе выдавалось следующее сообщение «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»

Поиски на просторах интернета выдали следующий способ. В таблице Config нашей базы данные необходимо удалить строки где поле FileName = commit или FileName = dbStruFinal или FileName=DynamicallyUpdated (для 8.3) или FileName=dynamicCommit (8.3), а также очистить таблицу ConfigSave. Поясню за что отвечают данные таблицы: Config — в данной таблице хранится конфигурация базы данных, ConfigSave — в данной таблице хранится рабочая конфигурация, т.е. до нажатия кнопки F7 в конфигураторе.

Открываем SQL Serger Managment Studio и открываем окно запросов по кнопке «New Query» открывает окно запросов.

В окне запросов пишем запросы и выполняем их:

delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘commit’
delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘dbStruFinal’
delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘DynamicallyUpdated’ (для версии 8.3)
delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘dynamicCommit’ (для версии 8.3)
delete from [ИмяНашейБазы].[dbo].[ConfigSave]

После выполнения данных запросов, конфигуратор запустился без проблем.

Случай №2

Причина ошибки входа в конфигуратор такая же как и в первом случае: конфликт блокировок при обновлении конфигурации.

Удаление строк в таблице Config и очистка таблицы ConfigSave помогло частично: конфигуратор открывался, но в предприятии не работали управляемые формы.

В данном случае приходило в голову 2 пути развития:

Восстановление из архива. В данном варианте было одно большое «НО»: так получилось что архив создался уже после обновления, т.е. архив был с ошибкой.
Была идея использовать конфигурацию распределенной базы, которая не обновилась, потому что файл для обмена был с ошибкой.

Для решения проблемы был выбран 2-ой вариант. Далее пошагово расскажу что делал.

Открываем SQL Serger Managment Studio и создаем произвольную базу, например Perenos. В этой базе создаем таблицу Config. Кто не знает sql для переноса данных из одной таблицы в другую, то у MS SQL есть замечательный сервис «SQL Server import and Export Wizard«. С помощью данного сервиса можно легко переносить данные из одной базу в другую. Чтобы запустить данный сервис необходимо нажать клавиши «ctrl+r» и в окне диалога написать команду « dtswizard «.
Переносим с помощью сервиса dtswizard данные таблицы Config нашей базы в таблицу Config базы Perenos.
Очищаем таблицу Config в нашей базе с помощью запроса delete from [ИмяНашейБазы].[dbo].[Config]
На сервере, где находится распределенная база запускаем сервис dtswizard и переносим данные из таблицы Config в такую же таблицу только в нашей базе.

Вот с помощью таких действий получилось быстро и с минимальным простоем восстановить работоспособность базы.

Источник

Проверка базы данных 1C на целостность и исправление ошибок MS SQL.

Делимся опытом, как исправить ошибки в логической целостности в базе 1С, размещенной на Microsoft SQL Server.

Поступила жалоба от бухгалтера о проблемах с проведением документов в 1С.

Из скриншота выяснилось, что 1С «ругается» на проблемы с согласованностью «внутри» базы данных и предлагает провести проверку на согласованность.

Переходим в SQL Server Management Studio и, сделав, на всякий случай, бэкап текущего состояния, выполняем проверку:

Для начала переводим нужную нам БД в однопользовательский режим

Запускаем Окно запросов (CTRL+N). Выбираем Новый запрос и вводим запрос Transact-SQL (T-SQL) в этом окне:

ALTER DATABASE KA
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE

Далее, вводим запрос на сканирование базы данных:

Проверка продлилась около 15 минут, после чего выдала следующее:

CHECKDB обнаружил 0 ошибок размещения и 766 ошибок согласованности, не связанных ни с одним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysdbfiles» (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysxmlcomponent» (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 49 ошибок согласованности в таблице «_AccRg1025» (идентификатор объекта 1778313595).
CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице «_AccRgAT21046» (идентификатор объекта 1826313766).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице «_AccRg1051» (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных «KA».

Вариант решения №1: восстановление из бэкапа выявило накопительный характер ошибки: чем раньше сделан бэкап – тем меньше в базе ошибок, вплоть до самого «дальнего» (14 дней). Примерно на третьем бэкапе количество ошибок перестало уменьшаться – стало ясно, что этим путём мы придём только к потере актуальности базы и проблему не решить

Вариант решения №2 : В справочной информации описаны три возможных варианта исправления этих ошибок, рассмотрим каждый:

Синтаксис поддерживается только для обеспечения обратной совместимости. Действия по восстановлению не выполняются.

Выполняет действия по восстановлению данных, которые можно выполнить без риска их потери. Это может быть быстрое восстановление (например, восстановление отсутствующих строк в некластеризованных индексах) или более ресурсоемкие операции (например, перестроение индекса).

Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.

Аргумент REPAIR_FAST нам не подходит, REPAIR_ALLOW_DATA_LOSS оставим на крайний случай — пробуем REPAIR_REBUILD:

DBCC CHECKDB(N’ka’, REPAIR_REBUILD) WITH NO_INFOMSGS

Не помогло, переводим базу данных обратно в многопользовательский режим:

ALTER DATABASE KA
SET MULTI_USER

На всякий случай, я попробовал провести обслуживание базы данных и перепроверил – результат тот же.

Решил провести тестирование и исправление информационной базы средствами 1С, на что получил ошибку

Источник

Восстановление базы 1С под SQL-Server

Иногда приходится столкнуться с ситуацией, когда плоды многолетней работы, находящиеся в SQL-базе данных оказываются под угрозой. Эта статья о том, как не допустить потерю данных, а в случае, если это всё-таки произошло, как восстановить данные из того, что осталось от некогда нормальной базы.

Итак, приступим. Ситуация следующая: имеется сервер с запущенной на нем 1С+SQL. Во время работы SQL базы рубанули питание. Результат плачевный: база находится в состоянии suspect, и когда 1с пытается к ней зацепиться, выдается ошибка, что мол соединиться невозможно т.к. база помечена suspect for recovery. Этот режим в принципе означает, что MSSQL Server попытается восстановить базу своими средствами. Я не стал ни чего трогать и оставил все на ночь, в надежде, что к утру база восстановится, но и утром было то же самое, и к базе, стало быть, ни как не подобраться. Backup по закону подлости имеется, но он трехдневной давности, плюс имеется куча документов которые проводятся лишь по базе, а по бумажным документам их нет, т.е. возможности вручную восстановить документы нет. Потратив кучу сил, и нервов, (которые, как известно не восстанавливаются :)), я пришел к следующей последовательности действий, необходимых для восстановления базы.

1) Основной принцип поначалу – не навреди. Глушим SQL server и копируем *.mdf и *.ldf файлы от базы в сторону.
2) В принципе, бывает, что состояние suspect возникает из-за того, что поменялись пути к файлам с базой (например, добавился новый диск в системе, который потом убрали, переименовали папку с базой и т.д.). Затем, конечно же, пути восстановили, но база все равно остается помеченной как suspect. Вот что мы делаем:
3) Запускаем SQL Server.
4) Пробуем подключить базу через Enterprise Manager:
Правой кнопкой по Databases, в появившемся меню выбираем All tasks->Attach database, затем в появившемся диалогов окне выбираем файл с базой (*.mdf) и устанавливаем необходимые параметры.
5) или через Query Analyser примерно такой командой:
a. sp_attach_db @dbname = ‘DemoXMB’,
b. @filename1 = ‘E:\Data\DemoXMB_Data.MDF’,
c. @filename2 = ‘E:\Data\DemoXMB_Log.LDF’
6) Пути к базе, естественно нужно заменить на свои. Если база подключилась, то, можно сказать, отделались легким испугом, если же нет, то продолжим.
7) Если log-файл не поврежден (*.ldf), а поврежден *.mdf (например, при подключении базы sql ругается на ошибки в mdf-файле), и режим сохранения backup’а стоит full, то восстанавливаем базу без восстановления лога транзакций, почти 100%, что все мучения на этом могут закончиться.
8) Если же наоборот, поврежден ldf-файл, но остался *.mdf файл, при подключении база ругается на отсутствие/повреждение лога транзакций. В этом случае можно воспользоваться ХП «sp_attach_single_file_db»

Например:
use master
EXEC sp_attach_single_file_db @dbname = ‘DemoXMB’,
@physname = ‘c:\mssql7\data\DemoXMB_Dat.mdf’

При выполнении этих команд, создастся файл DemoXMB_Log.ldf в том же каталоге где и база, размером 1MB и авторасширением.
Если есть *.MDF и *.LDF-файлы, или данные хранятся более чем в одном физическом файле (общее количество подключаемых физических файлов не должно превышать 16-ти), то следует использовать ХП «sp_attach_db»

Читайте также: Ремни для ремонта кресел

Например:
use master
EXEC sp_attach_db @dbname = ‘DemoXMB’,
@filename1 = ‘c:\mssql7\data\DemoXMB_Dat.mdf’,
@filename1 = ‘c:\mssql7\data\DemoXMB_Log.ldf’

Для подключения более 16-ти физических файлов к БД следует использовать команду:
CREATE DATABASE FOR ATTACH

Однако если ничего не помогло, оказались поврежденными оба файла и база всё еще в состоянии suspect, то можно попробовать сбросить состояние базы следующей последовательностью: (перед использованием этой ХП необходимо разрешить прямое изменение системных таблиц)
use master
go
Разрешаем прямое изменение системных таблиц:
sp_configure ‘allow updates’,1
go
reconfigure with override
go
Для сброса признака suspect выполняем в БД master ХП sp_resetstatus:
sp_resetstatus ‘DataBaseName’
go
А теперь запретим прямое изменение системных таблиц:
sp_configure ‘allow updates’,0
go
reconfigure with override
go

В принципе, когда я выполнил все эти шаги, статус suspect сбросился, НО! при попытке выполнить какие-либо действия SQL начинала ругаться, что база все еще в состоянии suspect. И тогда я сделал так:

Из QA выполняем скрипт:
Use master
go
sp_configure ‘allow updates’, 1
reconfigure with override
go

Там же выполняем :
update sysdatabases set status= 32768 where name = ‘ ‘

Перезапускаем SQL Server. В принципе база должна быть видна (в emergency mode).

Из QA выполняем:
USE ‘ ‘
GO
sp_dboption ‘ ‘, ‘single_user’, ‘true’
go
DBCC CHECKDB(‘ ‘, REPAIR_ALLOW_DATA_LOSS)
go

Если все в порядке, то:
sp_dboption ‘ ‘, ‘single_user’, ‘false’
go
Use master
go
sp_configure ‘allow updates’, 0
go

После этого стало возможно просмотреть таблицы базы из SQL, а вот работать с ней было невозможно. Теперь необходимо при помощи Data Transformation Services экспортировать данные в новую базу. После этого проводим восстановление/тестирование базы средствами 1С. Внимание! Многие не обращают внимания на этот очень важный пункт. В результате, вы можете в один прекрасный момент обнаружить, что база восстановлена, мягко говоря, не совсем корректно. Т.е. в документе вместо номенклатуры будет стоять нечто вроде 10122/ , это та проблема, которая возникла у меня, вариантов же может быть уйма. Поэтому лучше потерять время, но проверить базу средствами 1С.

Если уж совсем ничего не помогает, а данные страсть как нужно восстановить, есть еще сторонняя утилита под названием MSSQLRecovery . Утилита платная, но есть возможность воспользоваться демонстрационной версией, которую можно взять здесь: http://www.officerecovery.com/mssql/download_demo.htm . Программа очень простая, и восстановление базы сводится к трем шагам: 1) выбираем файл с базой; 2) выбираем путь куда сохранять; 3) Жмем кнопку recovery; Ждем. Программа разбирает SQL-базу по косточкам и складывает ее в отдельный каталог. Туда же она добавляет и .bat файл для восстановления базы из полученных «кусочков». Я ей так и не воспользовался, т.к. сумел восстановить базу предыдущими шагами.

Но! Здесь следует сделать паузу. Статья не была бы полной, если бы я не описал методы для предотвращения подобных проблем. Итак, самый простой и надежный способ: архивация, архивация и еще раз архивация. В Enterprise Manager заходим в меню Tools->Wizards->Management->Backup Wizard и настраиваем все необходимые параметры. В результате, у меня полный сброс SQL базы на диск происходит ночью, а затем каждые 15 минут backup изменений, внесенных в базу. В принципе, если бы у меня был такой backup, я бы за пару минут сделал откат назад, и продолжил бы попивать Coca-Cola :).

Источник