Ошибка при создании информационной базы информационная база разрушена

   Stim

07.06.12 — 09:23

загрузка рабочей базы из dt внезапно прервалась с этим сообщением.

бекап есть, но как загрузить его в рабочую базу, если она не запускается? База на SQL

   asp

1 — 07.06.12 — 09:24

удалить, создать новую, загрузить бэкап

   shamannk

2 — 07.06.12 — 09:24

В старой теме че не написал, нах новые плодить.

   Азат

3 — 07.06.12 — 09:24

(1) +100500

   mikecool

4 — 07.06.12 — 09:24

(0) все таки прервал….

   Maxus43

5 — 07.06.12 — 09:25

нормальный подход, рабочие базы с утра насиловать)

   mikecool

6 — 07.06.12 — 09:25

не стоит загружать базы в существующие, можно много глюков поиметь

вариант (1) считаю самым правильным

вот только не забывать ЖР сохранять перед этим )

   Stim

7 — 07.06.12 — 09:27

(6) зачем сохранять?

   Maxus43

8 — 07.06.12 — 09:28

(7) удаляй если не нужен

   Stim

9 — 07.06.12 — 09:28

(4) оно само. сожрало 3 Гб на диске и прервалось((

   mikecool

10 — 07.06.12 — 09:29

(7) удали базу в консоли сервера 1с и прими звезды при вопросе «а где события до сегодня?» )))

   EasyRider

11 — 07.06.12 — 09:30

скорей всего через некоторое время скуль базу вернет в рабочее состояние

   Нуф-Нуф

12 — 07.06.12 — 09:30

   Нуф-Нуф

13 — 07.06.12 — 09:30

(11) типа поиграет и отпустит?

   Feanor

14 — 07.06.12 — 09:31

Прерванный половой акт никогда ещё до добра не доводил!

   Midaw

15 — 07.06.12 — 09:31

(0) странные у тебя вопрос. бросай кипишь и создай новую.

   EasyRider

16 — 07.06.12 — 09:31

(13)типа откатит транзакцию

   shuhard

17 — 07.06.12 — 09:31

(0)  а на куя использовать в сиквельной базе dt для бэкапа, когда это в 100 быстрее делается средствами СУБД ?

   Feanor

18 — 07.06.12 — 09:31

кстати, было уже про то, что дт — не бэкап?

   Александр_Тверь

19 — 07.06.12 — 09:32

Да ты, автор, молодец.

сейчас еще окажется что бэкап сделат dt, который тоже не загружается… вот смеху-то будет.

   Спорт

20 — 07.06.12 — 09:32

(11) Чтобы уж точно база вернулась надо 3 раза проговорить в открытое окно SQL Server Management Studio: «Скуль-Сукуль, поиграй, да назад отдай!»

   shamannk

21 — 07.06.12 — 09:32

(0) А нахрена ты dt загружал?

   shuhard

22 — 07.06.12 — 09:32

(18) теперь ТС уже знает, что dt, выгруженный без ТиИ — мина замедленного действия

   andrewks

23 — 07.06.12 — 09:33

пятнично

   Нуф-Нуф

24 — 07.06.12 — 09:33

   Александр_Тверь

25 — 07.06.12 — 09:33

(22) об этом он узнает, и ощутит в полной мере, когда попытается восстановить «бэкап» из этого dt и это у него не получится.

   Stim

26 — 07.06.12 — 09:34

(24) точно сама

   andrewks

27 — 07.06.12 — 09:34

   Feanor

28 — 07.06.12 — 09:35

(26) а что база делала на системном разделе?

   Нуф-Нуф

29 — 07.06.12 — 09:35

не тупи, создай новую скуль базу и загрузи в нее

   Stim

30 — 07.06.12 — 09:35

(28) ничего, это серверная база

   Stim

31 — 07.06.12 — 09:36

(29) пути переписывать у всех овер900 пользователей мля..

   Feanor

32 — 07.06.12 — 09:36

(31) зачем? достаточно поменять на сервере 1С

   Александр_Тверь

33 — 07.06.12 — 09:36

(29) 50 на 50 что поможет если у него «бекап» в dt, который к тому же, уже раз не загрузился, очень велика вероятность, что и второй раз ничего не загрузится. Так что, ИМХОется мне, что нету у него базы, нету у него бэкапа… но он вот вот станет обладателем огромного опыта!

   asp

34 — 07.06.12 — 09:37

(31) если все правильно сделать, то не придется

   andrewks

35 — 07.06.12 — 09:37

(31) какие, нах, пути? ты чё-то совсем заврался, то у тебя база серверная, то у тебя пути какие-то

   EasyRider

36 — 07.06.12 — 09:37

(33)фотка в личке как раз для случая

   Stim

37 — 07.06.12 — 09:37

(35) новую с таким же именем не создать

   Feanor

38 — 07.06.12 — 09:38

(33) не загрузилась по ходу из-за того, что места на диске не хватило

   andrewks

39 — 07.06.12 — 09:38

(37) а в консоли 1с указать другую базу кто-то запретил?

   Stim

40 — 07.06.12 — 09:39

(39) ?? не понимаю

   shamannk

41 — 07.06.12 — 09:39

(40) У старой имя тож поменяй

   Stim

42 — 07.06.12 — 09:39

(41) точняк, сща

   mikecool

43 — 07.06.12 — 09:40

(12) если не удалять базу и загрузить из дт — журнал останется старый, хранится то он отдельно

   andrewks

44 — 07.06.12 — 09:41

   mikecool

45 — 07.06.12 — 09:41

(42) тебя точно абизяны покусали…

   ХочуСказать

46 — 07.06.12 — 09:42

(0)

бэкап скульный есть?

   Stim

47 — 07.06.12 — 09:43

(46) нету. делал dt

   ХочуСказать

48 — 07.06.12 — 09:43

сделай копию базы средствами скуля,

делается очень быстро

   ХочуСказать

49 — 07.06.12 — 09:43

(47) а копия базы есть на скуле?

   Александр_Тверь

50 — 07.06.12 — 09:43

   andrewks

51 — 07.06.12 — 09:43

(33) «но он вот вот станет обладателем огромного опыта!»

ага, причём после этого «опыта» несколько дней будет больно сидеть

   Feanor

52 — 07.06.12 — 09:44

(50) я не проходил. и не хочу проходить)))

   ХочуСказать

53 — 07.06.12 — 09:45

(47)

1. Что бы не дергаться и не напортачить из за этого, объясни пользоватлям, что доступа к базе до обеда по техническим причинам не будет

2. Если 100% рабочая копия или бэкап, то убивай разрушенную базу, если нет, то оставь, но переименуй

3. Создай рабочую базу из копии

   ХочуСказать

54 — 07.06.12 — 09:46

+(53)

Спешка нужна только лишь при ловле блох

   Пеппи

55 — 07.06.12 — 09:46

(53) а копии то уже и нет.

   Александр_Тверь

56 — 07.06.12 — 09:46

(51) во всем надо искать положительные стороны. База она что? Сегодня нету — завтра заново заведут. А опыт он на всю жизнь!

(52) я проходил На заре карьеры принял ошибочное решение и в итоге фирма торгующая молочкой с оч. короткими сроками годности (3-5 дней) 2/3 дня не могла оформлять документы и отправлять документы… это была (__,__)

   Midaw

57 — 07.06.12 — 09:47

(54) ситуация серьезная. можно говорить не про обед, а про день…

   ХочуСказать

58 — 07.06.12 — 09:47

(56) это не (___?___) это ламерство

   Stim

59 — 07.06.12 — 09:48

сколько будет загружаться новая база из дт в 250мб ? по времени

   Midaw

60 — 07.06.12 — 09:49

(58) это молодость

(56) я ждал этой ветки от Stim’а. с него энергия не контролируемая так и прёт. думаю повзрослеет после таких событий ) нахер всех слать со спешкой будет.

   Александр_Тверь

61 — 07.06.12 — 09:49

(58) Да как не назови. Ошибся и это привело к серьезным последствиям. Но получил бесценный опыт.

   Stim

62 — 07.06.12 — 09:50

бекапы есть(dt) и вчерашний и позавчерашний и копии бекапов на флешке тоже есть

   Александр_Тверь

63 — 07.06.12 — 09:51

(62) dt — это не бэкап.

dt- Это файл выгрузки, который можно, но не рекомендуется, использовать как бэкап.

Используй средства SQL.

   ХочуСказать

64 — 07.06.12 — 09:51

   Stim

65 — 07.06.12 — 09:51

(63) всю жизнь выгружал/загружал через dt, никаких проблем не имел, кроме этой

   Midaw

66 — 07.06.12 — 09:52

(62) не стоит на бэкапы в виде DT надеяться. с какого то времени они могут быть все битые. смело пробуй более старый ставить и какой нибудь да взлетит.

   Feanor

67 — 07.06.12 — 09:52

(65) уж сколько раз твердили миру…))

   andrewks

68 — 07.06.12 — 09:52

(64) «а рабочей базы нет? »  скорее всего, уже нет

   Midaw

69 — 07.06.12 — 09:52

(65) именно так всегда и бывает )

   ХочуСказать

70 — 07.06.12 — 09:52

(65) а ты бы у меня спросил, я бы тебе рассказал, что почти 10 лет назад Сергей Нуралиев заявил, что не гарантирует восстановления базы из dt,

это всего лишь сервисный межанизм для перехода на другой тип СУБД

   Midaw

71 — 07.06.12 — 09:53

(69)+ есть время до бэкапов и после того как начал нормальные бэкапы делать.

   Александр_Тверь

72 — 07.06.12 — 09:53

(65) продолжай дальше в том же духе и молись, чтобы ЭТА проблема была единственной и последней.

Причем молитва в данном случае, твоя самая надежная защита.

   ХочуСказать

73 — 07.06.12 — 09:54

Stim

ответь на (64)

какая модель восстановления стоит?

   Stim

74 — 07.06.12 — 09:54

(73) где посмотреть?

   Александр_Тверь

75 — 07.06.12 — 09:54

(73) не пугай человека незнакомыми словами

   Stim

76 — 07.06.12 — 09:55

+ загружаю сейчас в 2 новые серверные базы вчерашний и позавчерашний бекап.

сколько будет идти загрузка dt в 250Мб ?

   ХочуСказать

77 — 07.06.12 — 09:56

   Александр_Тверь

78 — 07.06.12 — 09:56

(76) от минуты до недели.

   Midaw

79 — 07.06.12 — 09:56

(76) долго. dt всегда долго загружается. 250МБ это по моему 0.5-2 часа и зависит от проца и диска.

   Feanor

80 — 07.06.12 — 09:57

а если учесть, что предыдущая попытка закончилась печалью, то и эта не факт, что загрузицца

   ХочуСказать

81 — 07.06.12 — 09:57

   Александр_Тверь

82 — 07.06.12 — 09:58

(81) что ты хочешь от человека?

Он не сможет откатить по журналу транзакций обратно, если у него нет опорного бэкапа. А его у него нету.

   Stim

83 — 07.06.12 — 09:58

   ХочуСказать

84 — 07.06.12 — 09:58

   Midaw

85 — 07.06.12 — 09:58

(81) ты сейчас насоветуешь. пускай DT вначале поднимет. потом извращается над бывшей рабочей

   andrewks

86 — 07.06.12 — 09:59

да почисть ты уже этот долбаный диск! или грузи на другой

   Stim

87 — 07.06.12 — 09:59

(86) сколько надо для загрузки-то??? 3,5 мало чтоле?

   Александр_Тверь

88 — 07.06.12 — 10:00

(86) думаю в данном случае варианты ответа:

1. нету другого диска, а этот на 20 гб. Но на нем система и суль стоят

2. а как это сделать?

   Midaw

89 — 07.06.12 — 10:00

(87) мало! твои 250МБ это сжатое.

   Stim

90 — 07.06.12 — 10:00

что-то важное хранится в

C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDatabuh_service20_log.LDF ??

можно его удалять, он 30Гб весит

   andrewks

91 — 07.06.12 — 10:00

(87) минимум гигов 10-15 освободи

   Midaw

92 — 07.06.12 — 10:01

(90) это у тебя значит не Simple

   ХочуСказать

93 — 07.06.12 — 10:01

   Александр_Тверь

94 — 07.06.12 — 10:01

   Stim

95 — 07.06.12 — 10:01

удалять-то можно??

   ХочуСказать

96 — 07.06.12 — 10:01

(95) нельзя, если это рабочая база…

переведи модель восстановления в simple

   Александр_Тверь

97 — 07.06.12 — 10:02

(95) правой кнопкой по базе в менеджере SQL и там есть операция шринк. Сделай шринк к логу транзакций.

   ХочуСказать

98 — 07.06.12 — 10:02

(95) ты меня слушать будешь или нет?

обижусь же

и из аськи удалю нахрен

   EasyRider

99 — 07.06.12 — 10:02

   Feanor

100 — 07.06.12 — 10:02

100

Зачем нужна эта статья

Есть такая очень правдивая шутка, мол, все администраторы делятся на 2 группы: одни делают бэкапы, а другие будут делать бэкапы. Обычно чем старше человек, тем больше вероятность того, что он принадлежит к первой категории. Впрочем, эта статья как раз и создана для того, чтобы читатель смог перейти в первую категорию

Стандартная документация программ 1С практически не затрагивает тему нештатной работы 1С:Предприятие; часто в этих статьях советуют использовать серверы с разными механизмами резервирования устройств, а также использовать источники бесперебойного питания; ну и, конечно же, иногда делать резервные копии, храня их на флешке, диске или дополнительных винчестерах

Но, как свидетельствует практика, большинство пользователей, и даже администраторов имеют привычку сначала испортить базу, а когда ее восстановить уже нельзя, как впрочем и данные в ней, тогда и кричат о помощи

Методы восстановления данных

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

1) запишите на бумаге дату и время, когда появились ошибки; это поможет намного быстрее найти и исправить ошибку, когда, например, вы будете просматривать логии. Если не помните точное время, запишите хотя бы приблизительное, или временные рамки, когда, по вашему мнению, могли начаться глюки и ошибки

2) запишите туда же текст ошибки, причем максимально точный – каждый символ и число из этого текста. Также нужно записать номер релиза СУБД, версию программы 1С:Предприятие, и ее текущую конфигурацию

– если возможно, сделайте скриншота экрана, когда на нем высветилась ошибка;

– сделайте пометку, может ли это быть результатом рассинхронизации узлов базы, или нет;

Например, текст ошибки может быть таким:

Ошибка SDBL:
Разрушена структура базы данных 1С:Предприятия. (pos=0)

Или на английском:

Server: Msg 945, Level 14, State 2, Line 1
Database ‘ db_zup’ cannot be opened because some of the files could not be activated.
Server: Msg 1813, Level 16, State 2, Line 1
Could not open new database ‘db_zup’. CREATE DATABASE is aborted

Иногда в MS SQL Server база данных может иметь статус Suspect

3) пока еще все помните и все находится в действии, попробуйте восстановить последовательность действий, которые вы делали до этого, и которые возможно были причиной возникновения ошибки;

– если в этом момент будете вносить изменения, сначала обязательно сделайте копию;

4) предложите вашему заказчику прислать базы данных с SQL Server’а или dt-файл, или же архивную копию каталога на адрес v8@1c.ru ;

– это обязательно нужно делать сразу, ведь если заказчик откажется, можно предложить ему платную версию ваших работ;

– для передачи данных в 1С нужно предоставить продукт, зарегистрированный в 1С, а также подписку на ИТС в текущем месяце; учтите, что сроки реакции 1С бывают медленные;

5) спросите у заказчика, какие резервные копии у его есть, или какие другие узлы базы; в дальнейшем их можно будет использовать для восстановления

– обязательно обратите внимание на актуальность этих копий – когда они были сделаны;

– для распределенных баз может быть полезен состав информации, которая регистрируется;

– спросите Заказчика о наличии dt-файла

6) определяем то, что вызвало ошибку – это описано во втором пункте;

– обычно источник ошибки – это MS SQL Server, но все равно нужно внимательно читать текст, исследовать ошибки PostgreSQL отдельно от ошибок MS SQL Server;

– бывает, что ответ уже заложен в источнике ошибки;

– стандартная документация программ 1С описывает такую возможную причины:

При запуске 1С:Предприятие начинает проверять, есть ли в информационной базе таблицы следующие элементы: Config, ConfigSave, Files, Params, _YearOffset, DBSchema, и если какого-то не находит, выдает сообщение о том, что ИБ разрушена

Еще один вариант описан сотрудников компании 1С:

Сообщение об ошибке может появляться в случае, когда отсутствует или заполнена поврежденными данными таблица под названием DBSchema, если в ней есть таблицы DBChanges и DBSchemaOG, но таблицы DBSchema DBSchemaOG не находятся

7) всегда можно поискать в Интернете решение для любого конкретного случая, в том числе того, который случился у вас;

7,1) если разрушена база в файловом варианте, в папке C:Program Files1cv81in можно найти утилиту под названием chdbfl.exe; используйте ее или попробуйте конвертирование в клиент-серверную версию; если это возможно, конечно;

7,2) В случае с СУБД PostgreSQL можно попробовать ввести команду pg_resetxlog, перед тем обязательно сделав резервные копии каталога DATA. Может быть, PostgreSQL таки запустится, но при этом потеряется часть данных;

7,3) При обменах данными. Войдя в режим предприятия, нужно сделать базу не подчиненной; далее выгрузите из центральной конфигурации и загрузите в периферийную базу, после этого снова сделайте периферийную базу подчиненной. Загружаем изменения в конфигурации, которые во время обмена были выгружены из центральной базы;

7,4) Когда найдены базы со статусом Suspect. Именно такой статус имеют базы, которые находятся в аварийном состоянии. Довольно часто причиной этого являются неполадки с журналом транзакций. Если попробовать подключить базу без журналов, может появиться такое сообщение про ошибку:

Server: Msg 945, Level 14, State 2, Line 1
Database ‘ db_zup’ cannot be opened because some of the files could not be activated.
Server: Msg 1813, Level 16, State 2, Line 1
Could not open new database ‘db_zup’. CREATE DATABASE is aborted

Для того чтобы решить такую проблему, можно создать новую базу с таким же именем, и аналогичными по имени и расположению файлами mdf и ldf; пропишите параметр базы autoclose в активное состояние, то есть введите autoclose = true

Тепер нужно подменить файл с расширением mdf. Можно также делать проверку физической целостности базы при помощи команды DBCC CHECKDB

Если сервер был остановлен, то сразу запускаем, не обращая внимания на статус базы, а в Query Analyzer выполняем такое:

Use master
go — позволяем изменять данные систeмных баз
sp_configure ‘allow updates’, 1 –- для 2000
reconfigure with override –- для 2000
go –- сохраняем значение
select status from sysdatabases where name = ‘имя базы’ –- для 2000
go –-изменяем статус данной базы
update sysdatabases set status= 32768 where name = ” –- для 2000

alter database set emergency –- для 2005
go

После перезапуска SQL Server прописываем в командной строке следующее:

Net stop mssqlserver
Net start mssqlserver

База должна быть видимой, если работаем в режиме emergency mode

Дальше создаем новый Журнал транзакций и проводим полное тестирование вот так:

DBCC REBUILD_LOG(‘имя_базы’, ‘ ‘)
GO
Use master
GO
sp_dboption ‘имя_базы’, ‘single_user’, ‘true’ –- для 2000

ALTER DATABASE SET SINGLE_USER –- для 2005
GO
USE имя_базы
GO
DBCC CHECKDB(‘имя_базы’, REPAIR_ALLOW_DATA_LOSS)

/*Этот код ищет Журнал транзакций по старому пути. Если база уже находится на другом компьютере, то нужно создать временный пустой Журнал транзакций в той же папке и на том же диске, что и раньше. После восстановление можно его перенести

Если у вас не получилось перевести базу в singleusermode, то проверку целостности может получить сделать через dbo only mode, для этого просто уберите знак – в строке:*/

— sp_dboption ”, ‘dbo use only’, ‘true’
GO
sp_dboption ”, ‘single_user’, ‘false’ –- для 2000

alter database set multi_user –- для 2005
GO
USE master
GO — запрещаем изменения в системных базах
sp_configure ‘allow updates’, 0 –- для 2000
GO

7,5) Откат к конфигурации базы данных. Эта ошибка исправляется, если открыть конфигуратор данных с помощью ключей запуска /RollbackCfg;

7,6) При тяжелых случаях, когда не запускается конфигуратор, а то и конфигурация не открывается, можно использовать такое, но только для СУБД MS SQL Server 2005:

USE [db_buh]
GO
DROP TABLE [dbo].[ConfigSave]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[ConfigSave](
[FileName] [nvarchar](128) NOT NULL,
[Creation] [datetime] NOT NULL,
[Modified] [datetime] NOT NULL,
[Attributes] [smallint] NOT NULL,
[DataSize] [int] NOT NULL,
[BinaryData] [image] NOT NULL,
PRIMARY KEY CLUSTERED
(
[FileName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
INSERT INTO ConfigSave
SELECT * FROM Config
GO
где [db_buh] – имя базы

7,7) наиболее тяжелый случай, когда конфигурация испорчен дальше некуда, но она является стандартной или похожа на стандартную, а также в случае если известен ее номер:

– создает чистую конфигурацию из стандартной;

– используем скрипт из пункта 7,6, но в нем вместо

SELECT * FROM Config

Прописываем SELECT * FROM [база_источник]dbo.Config

– снова выполняем скрипт, но не для [dbo].[ConfigSave], а теперь уже для [dbo].[Config];

– делаем реструктуризацию и реиндексацию

– выполняем ТиС, но с очисткой испорченных ссылок

Работает ли все это?

Конечно, гарантий успешности этих мероприятий никто не дает, но уже многим людям данные советы помогли; но самый главный совет – регулярно делайте бэкапы!

Теги материала: база, 1с, бухгалтерия, предприятие, сломалась база, зависла база, повредилась база, не открывается база

Зачем это надо

Все админы делятся на две категории:
1) те, которые делают бэкапы
2) те, которые будут делать бэкапы.

Как 2я категория становиться 1й категорией :).

В стандартной документации 1С не сказано про нештатную работу 1С:Предприятия. Во многих статьях рекомендуется использовать сервера с различными механизмами резервирования устройств, использовать источники бесперебойного питания и ДЕЛАТЬ РЕЗЕРВНЫЕ КОПИИ, храня их на отдельном носителе (от данных).

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

Методика

Ниже обобщил свой опыт помощи в таких случаях.

1. Зафиксируйте время возникновения ошибки на бумаге. (Это в дальнейшем поможет локализовать место изучения различных логов)

2. Запишите точный текст ошибки (а также номера релизов СУБД, 1С:Предприятие, конфигурации)
— если есть возможность сделать скриншот, сделайте
— пометьте, может ли быть это результатом рассинхронизации узлов базы

Вот некоторые возможные варианты текста ошибки:
Ошибка SDBL:
Разрушена структура базы данных 1С:Предприятия. (pos=0)

Произошла неизвестная ошибка на сервере 1С предприятие (80010108)

Server: Msg 945, Level 14, State 2, Line 1
Database ‘ db_zup’ cannot be opened because some of the files could not be activated.
Server: Msg 1813, Level 16, State 2, Line 1
Could not open new database ‘db_zup’. CREATE DATABASE is aborted.

В MS SQL Server база данных может оказаться со статусом «Suspect».

3. По горячим следам постарайтесь восстановить последовательность действий, приведшую к возникновению данной ошибки
— если будете вносить любые изменения в этот момент, сначало сделайте бэкап!

4. Предложите заказчику для расследования прислать на v8@1c.ru backup базы данных SQL сервера или dt-файл или архивную копию каталога для файлового варианта.
— это важно сделать сразу, так как это позволит в случаи отказа заказчиком предложить ему ПЛАТНЫЙ вариант Ваших работ
— для передачи в 1С надо предоставить зарегистрированный в 1С продукт и подписку на ИТС текущего месяца, сроки реакции в 1С не всегда быстрые

5. Поинтересуйтесь, какие резервные копии и другие узлы базы есть у Заказчика, чтобы можно было использовать для восстановления
— нас будет интересовать актуальность копии (возраст копии)
— для распределенных баз это может быть состав регистрируемой информации
— наличие dt-файла

6. Определите источник ошибки по 2 пункту.
— здесь чаще всего источником ошибки бывает MS SQL Server, однако надо внимательно прочитать текст, отдельно исследовать ошибки для PostgreSQL, так в последнем случае работа платформы отлажена конечно меньше

— часто в источнике ошибки уже заложен ответ

— в стандартной документации описан следующая возможная причина:
При старте 1С:Предприятие проверяет наличие в информационной базе таблицы
1. Config
2. ConfigSave
3. Files
4. Params
5. _YearOffset
6. DBSchema
и в случае отсутствия какой-нибудь из них выдается сообщение «информационная база разрушена».

— другой варинт описывает сотрудник 1С:
Такое сообщение об ошибке может быть выдано в случае, если отсутствует или содержит искаженные данные таблица DBSchema при условии, что имеются таблицы DBChanges и DBSchemaOG, или нет ни таблицы DBSchema, ни таблицы DBSchemaOG.

7. Поищите в Интернете и на этом форуме, и в этой статье решения для вашего случая
7.1 При разрушении базы в файловом варианте в каталоге C:Program Files1cv81in есть утилита chdbfl.exe. Воспользуйтесь этой утилитой или попробуйте конвертировать в клиент-серверный вариант (если это возможно).
7.2 Для варианта с СУБД PostgreSQL попробуйте использовать команду pg_resetxlog, предварительно сделав резервную копию каталога DATA. Возможно PostgreSQL запустится, но часть данных может быть потеряна.
7.3 При обменах. В режиме предприятия сделать базу не подчиненной. Выгрузить из центральной конфигурации, загрузить ее в переферийную базу. Сделать переферийную базу опять подчиненной. Загрузить изменения конфигурации, которые были при обмене выгружены из центральной.
7.4 База со статусом «Suspect». Такой статус присваивается базе в случаи аварийного состояния. Часто такой причиной является неисправность Журнала транзакций (transaction log). Попытка подключить базу без логов ожидается примерно такое сообщение об ошибке:
Server: Msg 945, Level 14, State 2, Line 1
Database ‘ db_zup’ cannot be opened because some of the files could not be activated.
Server: Msg 1813, Level 16, State 2, Line 1
Could not open new database ‘db_zup’. CREATE DATABASE is aborted.

Решить эту ситуацию можно созданием новой базы с таким же именем и такими же по именам и расположению .mdf и .ldf файлами, укажите параметр базы autoclose = true, чтобы можно было не останавливать сервер целиком.
Теперь подменяем файл .mdf . Можно также использовать проверку физической целостности базы командой DBCC CHECKDB.
Если останавливали сервер, Стартуем, не обращаем внимания на статус базы
и в Query Analyzer выполняем:

Use master
go — разрешаем изменения в системных базах
sp_configure ‘allow updates’, 1 –- для 2000
reconfigure with override –- для 2000
go –- запоминаем значение
select status from sysdatabases where name = ‘имя базы’ –- для 2000
go –-изменяем статус нашей базы
update sysdatabases set status= 32768 where name = ‘ ’ –- для 2000

alter database set emergency –- для 2005
go

После рестарта SQL Server (в командной строке):

Net stop mssqlserver
Net start mssqlserver

база должна быть видна (в emergency mode).

Создадим новый Журнал транзакций и выполним полное тестирование
DBCC REBUILD_LOG(‘имя_базы’, ‘ ’)
GO
Use master
GO
sp_dboption ‘имя_базы’, ‘single_user’, ‘true’ –- для 2000

ALTER DATABASE SET SINGLE_USER –- для 2005
GO
USE имя_базы
GO
DBCC CHECKDB(‘имя_базы’, REPAIR_ALLOW_DATA_LOSS)

/*ищет лог по старому пути. И если база уже перенесена на другую машину, то надо на время создать пустой лог в той же директории и на том же диске, что и был раньше. После восстановления его можно перенести (детач-аттач с новыми путями)*/
— Если Вам не удалось перевести базу в single user mode,
— то для проверки целостности данных можно попробовать dbo only mode
— для этого уберите «—» в строке ниже
— sp_dboption ‘ ’, ‘dbo use only’, ‘true’
GO
sp_dboption ‘ ’, ‘single_user’, ‘false’ –- для 2000

alter database set multi_user –- для 2005
GO
USE master
GO — запрещаем изменения в системных базах
sp_configure ‘allow updates’, 0 –- для 2000
GO

7.5 Вариант отката к конфигурации базы данных. Ошибка устраняется открытием конфигуратора данных ключами запуска /RollbackCfg.
7.6 Проверенное лекарство для тяжелых случаем, когда не запускается конфигуратор или не открывается конфигуруция (только для СУБД MS SQL Server 2005):

USE [db_buh]
GO
DROP TABLE [dbo].[ConfigSave]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[ConfigSave](
[FileName] [nvarchar](128) NOT NULL,
[Creation] [datetime] NOT NULL,
[Modified] [datetime] NOT NULL,
[Attributes] [smallint] NOT NULL,
[DataSize] [int] NOT NULL,
[BinaryData] [image] NOT NULL,
PRIMARY KEY CLUSTERED
(
[FileName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
INSERT INTO ConfigSave
SELECT * FROM Config
GO
где [db_buh] — имя базы

7.7 Смертельный номер, когда «убита» конфигурация, но она типовая или близко к типовой и известен ее номер.
— создаем чистую конфигурацию из типовой
— используем скрипт из 7.6, но вместо
SELECT * FROM Config
пишем
SELECT * FROM [база_источник]dbo.Config
— выполняем снова этот скрипт но уже не для [dbo].[ConfigSave], адл [dbo].[Config]
— выполняем реструктуризацию и реиндексацию
— выполняем обновление
— выполняем ТиС с очисткой битых ссылок

Работает ли это?

Пример, когда пункт 7.7 помог «в особо тяжелом» случаи в http://partners.v8.1c.ru/forum/thread…398#595398
Тут и сказочки конец, а кто слушал – будет делать бэкапы 🙂

ВНИМАНИЕ! ПЛАТНЫХ УСЛУГ ПО ВОССТАНОВЛЕНИЮ ДАННЫХ КОМПАНИЯ НЕ ОКАЗЫВАЕТ

Спасти рядовую пятницу

Пятница – это не только друг Робинзона. Это – почти выходной. Должен же быть в рабочем календаре день, когда можно подумать о горячих выходных и прохладных напитках. Как минимум, стоит остерегаться резких движений, чтобы сберечь настоящие выходные для команды и пользователей. Во многих софтверных компаниях считается дурным тоном выпускать новые релизы в конце недели. К примеру, Apple «катит» по вторникам. В Яндексе запрещено «катить» по пятницам и перед Новым Годом.
Но однажды пятнице не повезло. Когда сроки горят, а дедлайны давят, всегда найдется чему пойти не так. И дальнейшее развитие событий сильно зависит от компетенций вашей uber-команды.

Конфигуратор, у нас проблемы

Это было обычное обновление конфигурации. Структура данных не поменялась, бизнес-логика тоже. По «большой просьбе» одного из пользователей, решили обновить рабочую базу.
Одно «но»: технологическое окно уже закончилось и основные изменения конфигурации уже были запущены в работу.
«Надо!» – пользователь просит. Что ж, надо – значит надо: программист привычно нажал F7 и согласился с предложением Конфигуратора «обновить динамически».
Через пару часов стало понятно, что база умерла: попытка войти в режиме «1С:Предприятие» отправляло систему «в дамп» после исполнения нескольких строк модуля приложения. Конфигуратор открывался и работал, но попытки внести изменения также приводили к краху без подробностей в журнале регистрации и технологическом журнале.

В результате база перестала открываться. Совсем.
Попытки войти в «1С:Предприятие» не пускали пользователей дальше окна авторизации. Конфигуратор открывался и работал, но без толку для решения задачи: попытки обновить информационную базу и/или выполнить восстановление также приводили к краху.
Анализ СУБД показал, что динамическое обновление разрушило структуру таблиц. Теперь-то каждый разработчик в команде знает, что «динамические обновления» – это зло. И все знают неформальное название – «демоническое обновление». Да, с этого момента динамические обновления в компании для рабочей базы запрещены. Но «фарш невозможно провернуть назад» и утерянная база не запускается.
Утеряно несколько сотен документов реализации, с сотнями товарных позиций.

Сначала мы оценили, чем в итоге располагаем.
Не так много, но не безнадежно:
* Слепок информационной базы, который делается регулярно по расписанию каждые два часа. Нам «повезло» и восстанавливать потребуется 1 час 53 минуты работы пользователей.
* База, работоспособна на уровне СУБД.
* На уровне COM-соединения работоспособность также сохранилась,
* Проектная команда собралась из разных проектов. (Да, специалист в фирме франчайзи – это универсальный боец и швец, и тд. Пожалуй, это главное, что помогло решить вопрос оперативно).
С этим понятно. Какие потери?
* Примерно два часа работы нескольких сотен пользователей. В основном – документы реализации и заказы покупателей.
* Да, можно восстановить данные по первичке. Но! Представьте себе пару часов работы сотен пользователей в разгар рабочего дня.
* На календаре конец первого квартала – это годовая бухгалтерская, налоговая отчетность. Плюс квартальная отчетность перед партнерами.
* Плюс скоро начислять зарплату и вознаграждения по договорам.

Второй шаг – круг задач

Оценив масштаб последствий, стало очевидно, что ситуация исправима. Как выяснилось позже – это оптимистичный вывод, но оптимистам везет.
Итак, утерян относительно небольшой по времени период – чуть меньше двух часов работы пользователей.
Это сотни документов с табличными частями до сотен строк. Несколько сотен элементов справочников.
И надо было определить, какие из потерь критичны для результата, а что можно пропустить и решить в дальнейшем другими путями.
Например, очень непросто восстанавливать записи (а тем более, итоги) регистров бухгалтерии по двум причинам. Первая – это низкая производительность по сравнению с другими структурами данных. Вторая – сложность организации как в СУБД, так и на уровне объектной модели «1С:Предприятие».
Но так как за эти два часа ручные корректировки регистров бухгалтерии не выполнялись, то можно записи отдельно от документов не восстанавливать. Все движения, подчиненные регистраторам, можно восстановить перепроведением восстановленных документов.

Попытка 1. Тестирование-исправление ИБ через директиву командной строки Конфигуратора. Примерно так:
1cv8.exe config /IBCheckAndRepair -Rebuild
А также тестирование/исправление СУБД
dbcc checkdb(‘ ‘, REPAIR_ALLOW_DATA_LOSS )
Конфигуратор стартовал, висел в списке процессов некоторое время и дальше падал без объяснения причин. Технологический журнал при этом с упорством Капитана Очевидность сообщал о разрушении таблицы с планом обмена.

Попытка 2. Копирование таблиц Config, Configsave, Params и DBSchema из работоспособной копии ИБ средствами MS SQL
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
Это помогло – удалось пройти дальше окна авторизации. Но модуль приложения все равно падал с исключением при попытке опросить планы обмена. Отключить проверку в этом куске кода не удалось, так как попытки сохранить конфигурацию приводили к падению Конфигуратора на этапе анализа структуры ИБ
То есть мы продвинулись дальше, но какая разница – перепрыгнул ты пропасть на четверть или наполовину? Как говорится, go fish.

Попытка 3. Очистка таблицы configsave средствами MS SQL
Примерно так:
DROP TABLE [ConfigSave]
CREATE TABLE [ConfigSave]( [FileName] [nvarchar](128) NOT NULL, [Creation] [datetime] NOT NULL, [Modified] [datetime] NOT NULL, [Attributes] [smallint] NOT NULL, [DataSize] [int] NOT NULL, [BinaryData] [image] NOT NULL)
INSERT INTO ConfigSave SELECT * FROM Config
Тоже помогло, Но с тем же эффектом, что и предыдущая попытка.

Попытка 4. Копирование разрушенных таблиц из работоспособной копии ИБ средствами MS SQL
Оценив количество модифицированных таблиц, мы прикинули сколько SELECT’ов придется написать. и решили, что несколько дней без базы компания не выдержит

Решение, которое помогло

1. Была восстановлена база из «слепка», снятого за два часа до разрушения таблиц.
2. Дальше немного магии: код на 1С, который помог восстановить данные, накопленные пользователями со времени снятия крайнего слепка.
3. Так как платформа в режиме COM-соединения гораздо легче и более прозрачно оперирует с СУБД, то система успешно стартует и дает выполнить запросы.
Итак, код решения, которое сработало:

1. Из копии подключаемся к разрушенной рабочей базе через COM-соединение. В отличие от обычного подключения, сеанс стартует успешно

Перенос справочников 1С

2. Загружаем те справочники, которых еще нет в копии

Перенос документов 1С

3. Загружаем те документы, которых еще нет в копии

Проведение документов 1С

4. Чтобы восстановить движения, перепроводим проведенные документы, загруженные в копию

Выводы. Как избежать поломки структуры данных базы 1С?

Удалось ли нам спасти ту пятницу? И да, и нет.
У пользователей случился «сокращенный рабочий день» и тут, пожалуй, да – отдыхать полезно.
Большинство проектной команды получило свою порцию адреналина. И ушли с работы тоже вовремя.
Руководитель проекта и эксперт по технологическим вопросам крупных внедрений получили много интересной и поучительной работы на выходные 🙂
Успеху в этой ситуации способствовали регулярные бэкапы и быстрая диагностика. Бэкап облегчил восстановление. А диагностика «в восемь рук» позволила быстро найти тот вариант, который сработал. То ,что он оказался пятым по счету и его не было на Инфостарте, в школе или на форумах только подтверждает ценность проектного опыта команды.
Что делать в будущем во избежание подобных ситуаций? Всю округу соломкой не устелить, но вот чек-лист для критичных ситуаций.
• Диагностика
o Команде знать и уметь работать с:
– техническим журналом;
– подсистемой «Инструменты разработчика» (Сергей, привет и огромное спасибо за твой многолетний труд);
– Sql + инструменты администрирования субд;
– инструментом диагностики операционной системы и оборудования.
o Держать под рукой эти инструменты, желательно в виде коротких пошаговых инструкций и скриптов
• Лечение
– Будьте экспертом. Неважно в данном случае, лучший ты сыщик с дипломом или без диплома. Важен экспертный подход к решению задач
o Мыслить гибко
•Профилактика
– Бэкапы – регулярно
– Каждому знать, где лежат и как часто делаются
– Админам написать инструкции (а лучше скрипты) для оперативного восстановления.

Если Вы дочитали эту статью до конца, можно с уверенностью пожелать спокойных выходных!

Анатолий Бурнашев,
руководитель отдела внедрения ООО “Кодерлайн”

Содержание
1. Спасти рядовую пятницу
2. Конфигуратор, у нас проблемы
3. Что делать, шеф?
4. Второй шаг – круг задач
5. Попытки решения
5.1. Попытка 1 — тестирование-исправление ИБ через директиву командной строк
5.2. Попытка 2 — копирование таблиц Config, Configsave, Params и DBSchema из работоспособной копии ИБ средствами MS SQL
5.3. Попытка 3 — очистка таблицы configsave средствами MS SQL
5.4. Попытка 4 — копирование разрушенных таблиц из работоспособной копии ИБ средствами MS SQL
6. Решение, которое помогло:
6.1. Подключение
6.2. Перенос справочников 1С
6.3. Перенос документов 1С
6.4. Проведение документов 1С 
7. Выводы. Как избежать поломки структуры данных базы 1С

Спасти рядовую пятницу

Пятница – это не только друг Робинзона. Это – почти выходной. Должен же быть в рабочем календаре день, когда можно подумать о горячих выходных и прохладных напитках.  Как минимум, стоит остерегаться резких движений, чтобы сберечь настоящие выходные для команды и пользователей. Во многих софтверных компаниях считается дурным тоном выпускать новые релизы в конце недели. К примеру, Apple «катит» по вторникам. В Яндексе запрещено «катить» по пятницам и перед Новым Годом. 
Но однажды пятнице не повезло. Когда сроки горят, а дедлайны давят, всегда найдется чему пойти не так. И дальнейшее развитие событий сильно зависит от компетенций вашей uber-команды. 

Конфигуратор, у нас проблемы

Это было обычное обновление конфигурации. Структура данных не поменялась, бизнес-логика тоже. По «большой просьбе» одного из пользователей, решили обновить рабочую базу. 
Одно «но»: технологическое окно уже закончилось и основные изменения конфигурации уже были запущены в работу.
«Надо!» – пользователь просит. Что ж, надо – значит надо: программист привычно нажал F7 и согласился с предложением Конфигуратора «обновить динамически».
Через пару часов стало понятно, что база умерла: попытка войти в режиме «1С:Предприятие» отправляло систему «в дамп» после исполнения нескольких строк модуля приложения. Конфигуратор открывался и работал, но попытки внести изменения также приводили к краху без подробностей в журнале регистрации и технологическом журнале.

В результате база перестала открываться. Совсем.
Попытки войти в «1С:Предприятие» не пускали пользователей дальше окна авторизации. Конфигуратор открывался и работал, но без толку для решения задачи: попытки обновить информационную базу и/или выполнить восстановление также приводили к краху. 
Анализ СУБД показал, что динамическое обновление разрушило структуру таблиц. Теперь-то каждый разработчик в команде знает, что «динамические обновления» – это зло. И все знают неформальное название – «демоническое обновление». Да, с этого момента динамические обновления в компании для рабочей базы запрещены. Но «фарш невозможно провернуть назад» и утерянная база не запускается. 
Утеряно несколько сотен документов реализации, с сотнями товарных позиций. 

Что делать, шеф? 

Сначала мы оценили, чем в итоге располагаем.
Не так много, но не безнадежно:
* Слепок информационной базы, который делается регулярно по расписанию каждые два часа. Нам «повезло» и восстанавливать потребуется 1 час 53 минуты работы пользователей. 
* База, работоспособна на уровне СУБД.
* На уровне COM-соединения работоспособность также сохранилась, 
* Проектная команда собралась из разных проектов. (Да, специалист в фирме франчайзи – это универсальный боец и швец, и тд. Пожалуй, это главное, что помогло решить вопрос оперативно).
С этим понятно. Какие потери? 
* Примерно два часа работы нескольких сотен пользователей. В основном – документы реализации и заказы покупателей.
* Да, можно восстановить данные по первичке. Но! Представьте себе пару часов работы сотен пользователей в разгар рабочего дня.
* На календаре конец первого квартала – это годовая бухгалтерская, налоговая отчетность. Плюс квартальная отчетность перед партнерами. 
* Плюс скоро начислять зарплату и вознаграждения по договорам.

    Второй шаг – круг задач

 

Оценив масштаб последствий, стало очевидно, что ситуация исправима. Как выяснилось позже – это оптимистичный вывод, но оптимистам везет. 
Итак, утерян относительно небольшой по времени период – чуть меньше двух часов работы пользователей.
Это сотни документов с табличными частями до сотен строк. Несколько сотен элементов справочников.
И надо было определить, какие из потерь критичны для результата, а что можно пропустить и решить в дальнейшем другими путями.
Например, очень непросто восстанавливать записи (а тем более, итоги) регистров бухгалтерии по двум причинам. Первая – это низкая производительность по сравнению с другими структурами данных. Вторая – сложность организации как в СУБД, так и на уровне объектной модели «1С:Предприятие».
Но так как за эти два часа ручные корректировки регистров бухгалтерии не выполнялись, то можно записи отдельно от документов не восстанавливать. Все движения, подчиненные регистраторам, можно восстановить перепроведением восстановленных документов. 

Попытки решения

Попытка 1. Тестирование-исправление ИБ через директиву командной строки Конфигуратора. Примерно так:
1cv8.exe config /IBCheckAndRepair -Rebuild
А также тестирование/исправление СУБД
dbcc checkdb(‘<db_name>’, REPAIR_ALLOW_DATA_LOSS )
Конфигуратор стартовал, висел в списке процессов некоторое время и дальше падал без объяснения причин. Технологический журнал при этом с упорством Капитана Очевидность сообщал о разрушении таблицы с планом обмена.

 
Попытка 2. Копирование таблиц Config, Configsave, Params и DBSchema из работоспособной копии ИБ средствами MS SQL
ins ert into [base2009].[Dbo].[Config] sel ect * from [BaseCopy].[Dbo].[Config]
Это помогло – удалось пройти дальше окна авторизации. Но модуль приложения все равно падал с исключением при попытке опросить планы обмена. Отключить проверку в этом куске кода не удалось, так как попытки сохранить конфигурацию приводили к падению Конфигуратора на этапе анализа структуры ИБ 
То есть мы продвинулись дальше, но какая разница – перепрыгнул ты пропасть на четверть или наполовину? Как говорится, go fish. 

 
Попытка 3. Очистка таблицы configsave средствами MS SQL
Примерно так: 
DR OP TABLE [ConfigSave]
CRE ATE TABLE [ConfigSave]( [FileName] [nvarchar](128) NOT NULL, [Creation] [datetime] NOT NULL, [Modified] [datetime] NOT NULL, [Attributes] [smallint] NOT NULL, [DataSize] [int] NOT NULL, [BinaryData] [image] NOT NULL)
INS ERT IN TO ConfigSave SELECT * FR OM Config 
Тоже помогло, Но с тем же эффектом, что и предыдущая попытка.

 
Попытка 4. Копирование разрушенных таблиц из работоспособной копии ИБ средствами MS SQL
Оценив количество модифицированных таблиц, мы прикинули сколько SELE CT’ов придется написать… и решили, что несколько дней без базы компания не выдержит 

  Решение, которое помогло 

1. Была восстановлена база из «слепка», снятого за два часа до разрушения таблиц.
2. Дальше немного магии: код на 1С, который помог восстановить данные, накопленные пользователями со времени снятия крайнего слепка.
3. Так как платформа в режиме COM-соединения гораздо легче и более прозрачно оперирует с СУБД, то система успешно стартует и дает выполнить запросы. 
Итак, код решения, которое сработало:

Подключение

        1. Из копии подключаемся к разрушенной рабочей базе через COM-соединение.  В отличие от обычного подключения, сеанс стартует успешно
 

Перенос справочников 1С

        2. Загружаем те справочники, которых еще нет в копии

 

Перенос документов 1С

        3. Загружаем те документы, которых еще нет в копии

 

Проведение документов 1С

    4. Чтобы восстановить движения, перепроводим проведенные документы, загруженные в копию

Выводы. Как избежать поломки структуры данных базы 1С?

Удалось ли нам спасти ту пятницу? И да, и нет. 
У пользователей случился «сокращенный рабочий день» и тут, пожалуй, да – отдыхать полезно. 
Большинство проектной команды получило свою порцию адреналина. И ушли с работы тоже вовремя. 
Руководитель проекта и эксперт по технологическим вопросам крупных внедрений получили много интересной и поучительной работы на выходные
Успеху в этой ситуации способствовали регулярные бэкапы и быстрая диагностика. Бэкап облегчил восстановление. А диагностика «в восемь рук» позволила быстро найти тот вариант, который сработал. То ,что он оказался пятым по счету и его не было на Инфостарте, в школе или на форумах только подтверждает ценность проектного опыта команды. 
Что делать в будущем во избежание подобных ситуаций? Всю округу соломкой не устелить, но вот чек-лист для критичных ситуаций.
• Диагностика
o Команде знать и уметь работать с: 
— техническим журналом;
— подсистемой «Инструменты разработчика» (Сергей, привет и огромное спасибо за твой многолетний труд); 
— Sql + инструменты администрирования субд;
— инструментом диагностики операционной системы и оборудования.
o Держать под рукой эти инструменты, желательно в виде коротких пошаговых инструкций и скриптов
• Лечение
— Будьте экспертом. Неважно в данном случае, лучший ты сыщик с дипломом или без диплома. Важен экспертный подход к решению задач
o Мыслить гибко 
•Профилактика
— Бэкапы — регулярно
— Каждому знать, где лежат и как часто делаются
— Админам написать инструкции (а лучше скрипты) для оперативного восстановления.

 
Если Вы дочитали эту статью до конца, можно с уверенностью пожелать спокойных выходных!

Анатолий Бурнашев,
руководитель отдела внедрения ООО “Кодерлайн”