Ошибка загрузки информационной базы загружены не все данные 1с

Ошибка загрузки информационной базы.

Я

   LastSoldier

09.09.14 — 09:08

Всем привет! Появляется вот такая ошибка если загружать базу в Sql вариант, в файловой все нормально, как ее можно исправить?

Ошибка загрузки информационной базы. В информационную базу загружены не все данные

по причине:

Попытка вставки неуникального значения в уникальный индекс:

Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем «dbo._ChrcChngR14332» и индекса с именем «_ChrcC14332_ByNodeMsg_RNR». Повторяющееся значение ключа: (0x00000014, 0x941c0015f2efde5411e3bbbbb6d19ef7, <NULL>, 0x8642f7481ff1ee7b48906540f37d661e).

HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1

   vde69

1 — 09.09.14 — 09:11

ТИИС для файловой…

   LastSoldier

2 — 09.09.14 — 09:12

Уже делал несколько раз, не помогло (

   Галахад

3 — 09.09.14 — 09:12

Планы видов характеристик

   lxs

4 — 09.09.14 — 09:12

Не спасет..

   lxs

5 — 09.09.14 — 09:13

Платформа какая?

   LastSoldier

6 — 09.09.14 — 09:13

Платформа 1С 8.3.5.1119

   lxs

7 — 09.09.14 — 09:14

Экстремал.. Попробуй поднять под 4.465 хотя бы

   lxs

8 — 09.09.14 — 09:15

«Загружать базу в SQL» — выгружал как, чем, на какой платформе крутилась?

   lxs

9 — 09.09.14 — 09:15

+ все динамические обновления были завершены перед выгрузкой?

   LastSoldier

10 — 09.09.14 — 09:16

У меня сейчас стоит УТ 11.1.4.13, не типовая, я хочу загрузить не типовую конфигурацию 11.1.7.56 и выскакивает такая ошибка, пробовал загрузить типовую 11.1.7.56, то же самое, обновлял в файлов варианте, потом пробовал подгрузить базу в Sql и опять то же самое

   shuhard

11 — 09.09.14 — 09:17

(10) поставь на сиквел пустую 11.1.7.56 и сделай выгрузку/загрузку в идентичную конфигурацию из файловой

   LastSoldier

12 — 09.09.14 — 09:18

(8) Выгрузку и загрузку делаю через конфигуратор 1С, ну когда начинали работать все крутилось на 8.3.4.482

   lxs

13 — 09.09.14 — 09:18

нихрена не понял.. ты конфигурацию чтоли загружаешь?

   LastSoldier

14 — 09.09.14 — 09:19

(13) я пытался грузить конфу или базу

   LastSoldier

15 — 09.09.14 — 09:21

(13)  мне надо загрузить или уже обновленную базу или конфигурацию для обновления базы

   lxs

16 — 09.09.14 — 09:22

Почему именно загрузить? Сравнить и объединить не хочешь?

   LastSoldier

17 — 09.09.14 — 09:22

(11) я Вас не совсем понял, еще не полностью проснулся, можно  подробнее )

   LastSoldier

18 — 09.09.14 — 09:22

(16) и это пробовал, результат тот же

   lxs

19 — 09.09.14 — 09:22

Загрузка может порушить как раз индексы и структуру

   lxs

20 — 09.09.14 — 09:23

   shuhard

21 — 09.09.14 — 09:24

(17) берешь cf от файловой, создаешь пустую базу на стквеле, загрушаешь cf, берешь обработку выгрузказагрузкавидентичнуюконифграцию выгружаешь в xml из файловой, загружаешь в сиквельную

   LastSoldier

22 — 09.09.14 — 09:24

Так пишут что для этой конфигурации 11.1.7.56,Внимание! Текущая версия конфигурации «Управление торговлей», редакция 11.1 предназначена для использования с версией системы 1С:Предприятие 8 не ниже 8.3.5.1119.

   РенеДекарт

23 — 09.09.14 — 09:25

(0)>Появляется вот такая ошибка если загружать базу в Sql вариант, в файловой все нормально

— потому и нормально, что 1С — это не СУБД.

Она не отслеживает уникальность. А SQL — отслеживает.

(19)>Загрузка может порушить как раз индексы и структуру

— хватит ерунду говорить

   РенеДекарт

24 — 09.09.14 — 09:25

(21)>берешь cf от файловой, создаешь пустую базу на стквеле

— бессмысленно

   lxs

25 — 09.09.14 — 09:25

(23) Ну-ну..

   РенеДекарт

26 — 09.09.14 — 09:26

Здесь однозначно — надо выявлять (Tool1CD), какие записи-ключи задвоились, и их править каким-либо образом — в хексе, или еще как сможешь (например, удалить объекты из базы)

   lxs

27 — 09.09.14 — 09:26

(24) Ты решение предложи. А то флудить тут все умеют

   РенеДекарт

28 — 09.09.14 — 09:27

(25) гну-гну

что-что, а загрузка-выгрузка ПРАВИТ структуру 1С, а не ломает. Это используется везде и всюду, за неименеием лучшего.

   РенеДекарт

29 — 09.09.14 — 09:27

(27) вот и не флуди больше.

А думай.

   РенеДекарт

30 — 09.09.14 — 09:28

(27) а индексы, молодой человек, каждый раз можно создать заново. На то они и индексы.

   РенеДекарт

31 — 09.09.14 — 09:29

(0)вот эти два ключа и ищи:

— 941c0015f2efde5411e3bbbbb6d19ef7

— 8642f7481ff1ee7b48906540f37d661e

   РенеДекарт

32 — 09.09.14 — 09:31

(21) у него ДАННЫЕ битые (ключи задвоены, что не редкость в файловой 1С, когда она постоянно завершается некорректно/электричество отключается/много пользователей-зависает).

MS SQL (он — ТОЧНО), исключает саму возможность задвоения ключей на уровне структуры (уникальность записи).

   РенеДекарт

33 — 09.09.14 — 09:34

(21)>берешь обработку выгрузказагрузкавидентичнуюконифграцию выгружаешь в xml из файловой, загружаешь в сиквельную

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

   РенеДекарт

34 — 09.09.14 — 09:36

(0)>ChrcChng

— это что вообще за объект — СвойстваИКатегории, что ли? Всякие подобные метаданные частенько так бьются.

   LastSoldier

35 — 09.09.14 — 09:55

(32) пару раз такие завершения были, а кстета, забыл еще вот что написать. Если выгрузить сейчас базу с конфой 11.1.4.13 и загрузить ее в Sql то будет все нормально, а вот обновить конфу уже не получается

   LastSoldier

36 — 09.09.14 — 09:58

(31) а где эти ключи искать надо? я загружал свою базу с конфой 11.1.4.13 на Sql (мы так изначально и работаем) и находил там в таблице dbo.ChrcChngR14332, только что с ним делать дальше

   LastSoldier

37 — 09.09.14 — 10:08

Просто настал уже такой момент что надо обновить конфу УТ (11.1.4.13),  только пробовал обновлять сразу на 11.1.7.56 и с ней возникает такая ошибка, может это проблема конфигурации?

   РенеДекарт

38 — 09.09.14 — 10:20

(36)> я загружал свою базу с конфой 11.1.4.13 на Sql (

— если УЖЕ загрузил в SQL, этой ошибки не будет никогда.

Ошибка именно в том наборе данных, который не загружается.

   РенеДекарт

39 — 09.09.14 — 10:22

(37)>и с ней возникает такая ошибка, может это проблема конфигурации?

— Ошибка в задвоении. Все.

Если уберешь каким-либо способом задвоение (может, тут и обновление поможет — вправит на место типовые ключи), то и ок.

Ты даже не посомтрел, что за данные за этими ключами.

   РенеДекарт

40 — 09.09.14 — 10:24

(35)>а вот обновить конфу уже не получается

— сделай все в файловой (обновление и все такое), и попробуй удалить «лишние» объекты после обновления. Вместе с объектами удалятся и ключи, и SQL уже не будет ругаться.

Но для этого тебе нужно выяснить, что за объекты с задвоенными ключами.

   LastSoldier

41 — 09.09.14 — 10:26

(40) «Но для этого тебе нужно выяснить, что за объекты с задвоенными ключами.»- а как это можно сделать?

   РенеДекарт

42 — 09.09.14 — 10:27

(36)>я загружал свою базу с конфой 11.1.4.13 на Sql (мы так изначально и работаем) и находил там в таблице dbo.ChrcChngR14332

— тут и не будет никаких задвоений, задвоенность «появляется» после обновления.

Точнее, страые объекты либо не удаляются, как надо, либо не надписываются. А может, и еще как-то остаются, но итог — «их» ключи мешают «новым» данным с теми же ключами.

   РенеДекарт

43 — 09.09.14 — 10:28

(41)Tool1Cd на файловой «битой» базе. И Вперед, смотреть и разбираться.

   LastSoldier

44 — 09.09.14 — 10:30

(43) я так понимаю на файловой, но уже с обновленной конфой 11.1.7.56?

   РенеДекарт

45 — 09.09.14 — 10:30

(42)>»их» ключи мешают «новым» данным с теми же ключами.

— типовой пример — в ПланеВидовРасчета оказывается два предопределенных вида начисления.

Соответсвенно, один надо каким-то образом удалить, и так, чтобы ссылочность не пострадала (т.е. сначала все ссылке «перевести» на новый, оставляемый объект).

   РенеДекарт

46 — 09.09.14 — 10:31

(44) да

В любом другом случае все ключи у тебя будут уникальными.

   LastSoldier

47 — 09.09.14 — 10:47

А эта прога Tool1Cd поддерживает версию 8.3.5.1119? Если можно дай пожалуйста ссылку на скачивание, а то  я  в гугле нашел или с вирусами или платную (

   МихаилМ

48 — 09.09.14 — 15:23

Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:

«Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла ‘D:1CBASESNewDB/1Cv8.1CD’«

Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).

Итак, причин возникновения такой ошибки может быть несколько:

1. Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб). Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки «SQL базомер» (или аналогов). 
2. Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.

С первым случаем все понятно — если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к «тяжелым» документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.

Регистры накопления — отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.

Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание «зависших» остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у «нерадивых» клиентов. ))

Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?

Это значит, что у вас второй случай — проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.

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

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

Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.

Включаем технологический журнал — в папку «С:Program Files (x86)1cv82__НомерВерсииПлатформы__inconf» (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:

<?xml version=»1.0″ encoding=»UTF-8″?>
<config xmlns=»http://v8.1c.ru/v8/tech-log»>
         <dump create=»true» location=»D:1CBASESdumps» type=»0″ prntscrn=»true»/>
         <log history=»3″ location=»D:1CBASESlogs»>
         <event>
                      <eq property=»name» value=»dbv8dbeng»/>
         </event>
         <event>
                      <eq property=»name» value=»excp»/>
         </event>
         <property name=»all»/>
         </log>
</config>

Внимательно следим за тем, чтобы каталоги для дампов и логов:

1. Существовали
2. Различались
3. Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.

Перезапускаем конфигуратор (при этом включается технологический журнал) и заново пробуем загрузить наш .DT. После возникновения ошибки идем в каталог для логов, находим там файл лога, содержащий нашу ошибку, и внимательно читаем его.

Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).

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

А дальше начинается самое интересное — нужно попытаться угадать, что именно в структуре вашей таблицы приводит к ошибке индексации.

В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки — так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы «1С» высказался на партнерском форуме еще в 2007 году:

«Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий.«

 И действительно, в 2013 году ничего не изменилось — в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка .DT останавливается с ошибкой.

Лично мне помогло отключить для проблемного измерения флажок «Использование в итогах», т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы — более строго ограничить размер строки, например. Читал, что некоторым это помогало.

Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.

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

Если SQL-копии нет под рукой, то можно попробовать исправить прямо на вашей недозагруженной файловой копии. После принятия изменений запускайте «Тестирование и исправление» в режиме реструктуризации таблиц базы данных. Индексы будут созданы платформой заново и, можно надеяться, уже без ошибок.

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

Удачи вам!