Ошибка загрузки информационной базы. |
Я |
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
1 — 09.09.14 — 09:11
ТИИС для файловой…
2 — 09.09.14 — 09:12
Уже делал несколько раз, не помогло (
3 — 09.09.14 — 09:12
Планы видов характеристик
4 — 09.09.14 — 09:12
Не спасет..
5 — 09.09.14 — 09:13
Платформа какая?
6 — 09.09.14 — 09:13
Платформа 1С 8.3.5.1119
7 — 09.09.14 — 09:14
Экстремал.. Попробуй поднять под 4.465 хотя бы
8 — 09.09.14 — 09:15
«Загружать базу в SQL» — выгружал как, чем, на какой платформе крутилась?
9 — 09.09.14 — 09:15
+ все динамические обновления были завершены перед выгрузкой?
10 — 09.09.14 — 09:16
У меня сейчас стоит УТ 11.1.4.13, не типовая, я хочу загрузить не типовую конфигурацию 11.1.7.56 и выскакивает такая ошибка, пробовал загрузить типовую 11.1.7.56, то же самое, обновлял в файлов варианте, потом пробовал подгрузить базу в Sql и опять то же самое
11 — 09.09.14 — 09:17
(10) поставь на сиквел пустую 11.1.7.56 и сделай выгрузку/загрузку в идентичную конфигурацию из файловой
12 — 09.09.14 — 09:18
(8) Выгрузку и загрузку делаю через конфигуратор 1С, ну когда начинали работать все крутилось на 8.3.4.482
13 — 09.09.14 — 09:18
нихрена не понял.. ты конфигурацию чтоли загружаешь?
14 — 09.09.14 — 09:19
(13) я пытался грузить конфу или базу
15 — 09.09.14 — 09:21
(13) мне надо загрузить или уже обновленную базу или конфигурацию для обновления базы
16 — 09.09.14 — 09:22
Почему именно загрузить? Сравнить и объединить не хочешь?
17 — 09.09.14 — 09:22
(11) я Вас не совсем понял, еще не полностью проснулся, можно подробнее )
18 — 09.09.14 — 09:22
(16) и это пробовал, результат тот же
19 — 09.09.14 — 09:22
Загрузка может порушить как раз индексы и структуру
20 — 09.09.14 — 09:23
Короче, пробуй под 4.465.
5ка еще сырая
21 — 09.09.14 — 09:24
(17) берешь cf от файловой, создаешь пустую базу на стквеле, загрушаешь cf, берешь обработку выгрузказагрузкавидентичнуюконифграцию выгружаешь в xml из файловой, загружаешь в сиквельную
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 от файловой, создаешь пустую базу на стквеле
— бессмысленно
25 — 09.09.14 — 09:25
(23) Ну-ну..
26 — 09.09.14 — 09:26
Здесь однозначно — надо выявлять (Tool1CD), какие записи-ключи задвоились, и их править каким-либо образом — в хексе, или еще как сможешь (например, удалить объекты из базы)
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
— это что вообще за объект — СвойстваИКатегории, что ли? Всякие подобные метаданные частенько так бьются.
35 — 09.09.14 — 09:55
(32) пару раз такие завершения были, а кстета, забыл еще вот что написать. Если выгрузить сейчас базу с конфой 11.1.4.13 и загрузить ее в Sql то будет все нормально, а вот обновить конфу уже не получается
36 — 09.09.14 — 09:58
(31) а где эти ключи искать надо? я загружал свою базу с конфой 11.1.4.13 на Sql (мы так изначально и работаем) и находил там в таблице dbo.ChrcChngR14332, только что с ним делать дальше
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 уже не будет ругаться.
Но для этого тебе нужно выяснить, что за объекты с задвоенными ключами.
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 на файловой «битой» базе. И Вперед, смотреть и разбираться.
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) да
В любом другом случае все ключи у тебя будут уникальными.
47 — 09.09.14 — 10:47
А эта прога Tool1Cd поддерживает версию 8.3.5.1119? Если можно дай пожалуйста ссылку на скачивание, а то я в гугле нашел или с вирусами или платную (
48 — 09.09.14 — 15:23
МихаилМ
49 — 09.09.14 — 15:33
+(48)
либо отмените создание индекса (PK)
по аналогии с
v8: Ошибка в базе. Ошибка в таблице Config.
после загрузки исправьте неуникальность
и создайте индекс
база 1с в файловом варианте. размер 25 ГБ. в базе работают 10 человек. конфигурация бухгалтерия 2.0 типовая. возникла задача перехода на sql, так как тормоза файлового варианта терпеть уже нереально (провозка входящего поручения ~10 минут). при загрузке базы на сервер 1с + PostgreSQL возникает ошибка
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Попытка вставки неуникального значения в уникальный индекс:
ERROR: could not create unique index «_docume1458_bydatakey_rr»
DETAIL: Key (_idrref, _nodetref, _noderref)=(xa6fc14dae9b1cbaf11e508ef2a672372, x00000004, xa746c1641f48a0a911e0f75662bec052) is duplicated.
смещение дат 2000 пробовал. результата нет. гуглил, ответа не найти. советуют отменить проводку проблемных документов, но не говорят как их найти(
-
Вопрос заданболее трёх лет назад
-
3098 просмотров
вопрос был решен с помощью обработки по поиску документов по uid.
infostart.ru/public/118578
выгрузил 4 документа, удалил, после переноса загрузил обратно. всем спасибо за помощь
Пригласить эксперта
Вы серьезно?!! )) Как вам удалось без падений дожить на файловом варианте до такого объема? ) Даже не верится.
гуглил, ответа не найти
Плохо гуглил. Используй ПолучитьСтруктуруХраненияБазыДанных и ищи нужную тебе таблицу. Не уверен, но возможно получиться получить объект по УИД — это длинный ряд цифр во второй строке.
На инфостарте есть готовые обработки, поищи.
-
Показать ещё
Загружается…
13 июн. 2023, в 22:21
10000 руб./за проект
13 июн. 2023, в 21:59
2000 руб./за проект
13 июн. 2023, в 20:23
5000 руб./за проект
Минуточку внимания
Ко мне обратился системный администратор одного из клиентов с проблемой, представленной на картинке:
Я сразу понял, что он пытается загрузить данные в базу из DT, подумал, что он пытается восстановить базу из архива и сказал всё что я думаю об архивации баз 1С в DT: «DT — ненадежный формат, 1С его не рекомендует использовать для бэкапов«.
Но, к счастью, оказалось, что админ просто пытается перенести базу из файловой в SQL. Полный текст ошибки оказался такой:
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Нарушено условие уникальности данных.
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 10.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._InfoRg29405" и индекса с именем "_InfoRg29405_1". Повторяющееся значение ключа: (0x20002000200020002000200020002000, 20002000200, 200020002000, 2001-01-01 20:00:20).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1Я попытался найти обработку, которая позволит по идентификатору регистра определить, что это за регистр. Но увы, у меня была версия только для обычных форм «Список метаданных«.
Тогда я нашел другой способ определения идентификатора, через выгрузку файлов базы данных.
Но администратор оказался шустрее, он запустил ТИИ с удалением битых ссылок, в итоге чего была определена проблема:
Проверка логической целостности. РегистрСведений.ЗамерыВремени.Измерение.КлючеваяОперация <Объект не найден> (77:20002000200020002000200020002000):20 002 000 200:200 020 002 000:01.01.0001 20:00:20
Неверная ссылка. Запись удалена.В итоге стало ясно, что битая запись была в регистре «Замеры времени», в общем то бесполезном.
Так удалось перенести базу в SQL-формат. Иногда пользователи находят более простые решения, чем программисты.
Объем: 0.2 час.
Что делать, если архив базы загружается в файловом варианте с ошибкой «Превышен максимально допустимый размер внутреннего файла», а загрузить очень надо? Постараюсь примерно описать технологию, которую нам удалось разработать при активном участии Виктора Сосновского из фирмы «1С» на партнерском форуме.
Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:
«Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла ‘D:1CBASESNewDB/1Cv8.1CD’«
Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).
Итак, причин возникновения такой ошибки может быть несколько:
- Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб). Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки «SQL базомер» (или аналогов).
- Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.
С первым случаем все понятно — если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к «тяжелым» документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.
Регистры накопления — отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.
Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание «зависших» остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у «нерадивых» клиентов. ))
Что же делать, если каждая таблица вашей базы размером менее 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>
Внимательно следим за тем, чтобы каталоги для дампов и логов:
- Существовали
- Различались
- Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.
Перезапускаем конфигуратор (при этом включается технологический журнал) и заново пробуем загрузить наш .DT. После возникновения ошибки идем в каталог для логов, находим там файл лога, содержащий нашу ошибку, и внимательно читаем его.
Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).
По цифрам из названия индекса с помощью обработки «Структура хранения таблиц базы данных» (или аналогов, которые умеют показывать индексы) находим, какой таблице принадлежит данный индекс. У меня это оказалась таблица оборотов одного из нетиповых регистров накопления.
А дальше начинается самое интересное — нужно попытаться угадать, что именно в структуре вашей таблицы приводит к ошибке индексации.
В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки — так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы «1С» высказался на партнерском форуме еще в 2007 году:
«Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий.«
И действительно, в 2013 году ничего не изменилось — в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка .DT останавливается с ошибкой.
Лично мне помогло отключить для проблемного измерения флажок «Использование в итогах», т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы — более строго ограничить размер строки, например. Читал, что некоторым это помогало.
Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.
Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить .DT и попытаться перезагрузить его в файловой версии.
Если SQL-копии нет под рукой, то можно попробовать исправить прямо на вашей недозагруженной файловой копии. После принятия изменений запускайте «Тестирование и исправление» в режиме реструктуризации таблиц базы данных. Индексы будут созданы платформой заново и, можно надеяться, уже без ошибок.
Кому особо не повезло и ошибка вылезла снова — тому следует повторить сначала всю процедуру, начиная с анализа логов. Возможно, проблемная таблица была не одна, или вам не удалось решить проблему с размерами полей, входящих в индекс.
Удачи вам!
1С 8 Ошибка СУБД: Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных «Торговля» переполнен. Причина: «ACTIVE_TRANSACTION»
Описание ошибки:
При попытке восстановления архива базы в клиент-серверную версию возникла ошибка:
Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных «Торговля» переполнен. Причина: «ACTIVE_TRANSACTION».
HRESULT=80004005, SQLSrvr: SQLSTATE=42000, state=4, Severity=11, native=9002, line=1
Найденные решения:
Решается проблема тем, что необходимо отключить в параметрах sql-базы ограничение на рост журнала транзакций. И на всякий случай установить режим восстановления в значение simple.
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
19-11-2015
Журавлев А.С.
(www.azhur-c.ru)