Ошибка при попытке выборки логической страницы sql 1с
Поступила жалоба от бухгалтера о проблемах с проведением документов в 1С.
Из скриншота выяснилось, что 1С «ругается» на проблемы с согласованностью «внутри» базы данных и предлагает провести проверку на согласованность.
Переходим в SQL Server Management Studio и, сделав, на всякий случай, бэкап текущего состояния, выполняем проверку:
Для начала переводим нужную нам БД в однопользовательский режим
Запускаем Окно запросов (CTRL+N). Выбираем Новый запрос и вводим запрос Transact-SQL (T-SQL) в этом окне:
ALTER DATABASE KA
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE
Далее, вводим запрос на сканирование базы данных:
USE [ka]
GO
DBCC CHECKDB(N'ka') WITH NO_INFOMSGS
GO
Проверка продлилась около 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_REBUILD
Выполняет действия по восстановлению данных, которые можно выполнить без риска их потери. Это может быть быстрое восстановление (например, восстановление отсутствующих строк в некластеризованных индексах) или более ресурсоемкие операции (например, перестроение индекса).
REPAIR_ALLOW_DATA_LOSS
Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.
Аргумент REPAIR_FAST нам не подходит, REPAIR_ALLOW_DATA_LOSS оставим на крайний случай - пробуем REPAIR_REBUILD:
DBCC CHECKDB(N'ka', REPAIR_REBUILD) WITH NO_INFOMSGS
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".
Не помогло, переводим базу данных обратно в многопользовательский режим:
ALTER DATABASE KA
SET MULTI_USER
На всякий случай, я попробовал провести обслуживание базы данных и перепроверил – результат тот же.
Решил провести тестирование и исправление информационной базы средствами 1С, на что получил ошибку
Здравствуйте!
В связи с аварийным отключением сервера при попытке проведения реализации - выдает ошибку:
Проблемы наблюдаются только с проведением реализаций, все остальные документы - проводятся.
Бекап сделали, но в нем сидит та же проблема, т.е. восстановление не помогает.
ТИИ и выгрузку информационной базы в файл *.dt не получается сделать, т.к. выдается такая же ошибка.
Подскажите пожалуйста, что в данной ситуации можно сделать?
(1) folwing, это повреждение базы на самом SQL сервере, судя по скрину - SQL 2008. В Вашем случае быстрее будет поднять бэкап до сбоя и выгрузками=загрузками перенести недостающие документы.
Далее запускаем в SQL Management Studio и выполняем DBCC CHECKDB. Выполняем ее так, чтобы данные не терялись, параметр REPAIR_ALLOW_DATA_LOSS оставим на случай совсем безнадежный.
Например, наша база называется Office
Выполняем следующие запросы:
ALT ER DATABASE Office
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB (N'Office', REPAIR_REBUILD) WITH NO_INFOMSGS
GO
Msg 8928, Level 16, State 1, Line 2
Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data): Page (1:3605) could not be processed. See other errors for details.
The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data), page (1:3605). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data). Page (1:3605) was not seen in the scan although its parent (1:6481) and previous (1:8859) refer to it. Check any previous errors.
Repairing this error requires other errors to be corrected first.
CHECKDB found 0 allocation errors and 8 consistency errors in table 'DT3311' (object ID 1970106059).
CHECKDB found 0 allocation errors and 43 consistency errors in database 'Office'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Office, repair_rebuild).
После проверки выполняем запрос для дальнейших операций с базой данных:
ALT ER DATABASE Office
SET MULTI_USER;
SET SINGLE_USER - это моонопольный режим уровня SQL, после выполнения восстановления обязательно сделайте SET MULTI_USER
Все началось с того, что после проблем с жестким диском на сервере и "не совсем удачным" восстановлением рабочей базы данных 1С начала сообщать "could not continue scan with nolock" при проведении документов и закрываться с непоправимой ошибкой. Бэкап был, но не самый свежий, а данные терять не хотелось. Что же лучше делать?
Первым делом нужно сделать резервную копию.
Далее запускаем в SQL Management Studio и выполняем DBCC CHECKDB. Выполняем ее так, чтобы данные не терялись, параметр REPAIR_ALLOW_DATA_LOSS оставим на случай совсем безнадежный.
Например, наша база называется Office
Выполняем следующие запросы:
ALTER DATABASE Office
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB (N'Office', REPAIR_REBUILD) WITH NO_INFOMSGS
GO
Msg 8928, Level 16, State 1, Line 2
Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data): Page (1:3605) could not be processed. See other errors for details.
The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data), page (1:3605). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data). Page (1:3605) was not seen in the scan although its parent (1:6481) and previous (1:8859) refer to it. Check any previous errors.
Repairing this error requires other errors to be corrected first.
CHECKDB found 0 allocation errors and 8 consistency errors in table 'DT3311' (object ID 1970106059).
CHECKDB found 0 allocation errors and 43 consistency errors in database 'Office'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Office, repair_rebuild).
После проверки выполняем запрос для дальнейших операций с базой данных:
ALTER DATABASE Office
SET MULTI_USER;
Как восстанавливать поврежденные страницы писать не буду. Статья рассчитана на простое администрирование и поможет даже при модели Simple. Те, кто делают бэкапы логов журнала транзакций очень-очень часто, сюда заходить не будут. Единственное условие - нам потребуется резервная копия (будем надеяться, что по теории вероятности самые свежие данные мы спасли без повреждений и бэкапы хоть иногда делали).
Как видим, все ошибки относятся к index или index Это говорит о том, что повреждены данные. Но не будем отчаиваться и воспользуемся резервной копией.
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xacafd5b7; actual: 0x21c9cf6a). It occurred during a read of page (1:8473) in database ID 8 at offset 0x00000004232000 in file 'E:\SQL_Data\Office.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Обращаем внимание, на какой строке таблицы останавливается запрос при полном показе содержимого таблицы в графическом интерфейсе. Например, он показал нам данные до строки 1915.
Проверяем: запрос Select top 1915 * From DT3311 выполняется, а Select top 1916 * From DT3311 - уже нет.
Смотрим резервную базу, поле IDDOC в таблице начиная со строки 1916, это документ с ID ' 1SP '
В рабочей базе мы ничего с документом не можем сделать: ни открыть его в 1С, ни прочитать его табличную часть, ни удалить его. Что делать?
Предлагаю перебросить по кусочкам данные из разных баз (рабочей и резервной), удалить таблицу в рабочей базе, создать ее повторно и положить данные на место.
Создаем временную базу test, в ней создаем такую же таблицу DT3311 (для тех, кто не знает как это сделать быстро - картинки ниже на примере создания индексов) и выполняем запрос:
Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC <> ' 1SP '
Запрос выполнился без ошибок. Это говорит о том, что других данных с "мусором" в этой таблице нет.
Данные о поврежденном документе берем из резервной копии. Выполняем запрос в резервной базе:
Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC = ' 1SP '
Теперь в тестовой базе есть полные данные. Удаляем таблицу в рабочей базе, создаем заново и выполняем запрос:
Insert into DT3311
Select * From Test.dbo.DT3311
Пробуем прочитать полностью другие таблицы, ведь мы помним, что не проводились документы. Выясняется, что не могут прочитаться некоторые таблицы итогов регистров (RGXXX). В данном случае можно просто удалить эти таблицы, данные в них восстановит сама 1С. Заходим монопольно в 1С: Предприятие, сдвигаем ТА на самый первый документ, затем на самый последний проведенный документ. В результате итоги по регистрам пересчитаются.
Производим повторную проверку ошибок и убеждаемся в их отсутствии.
Беремся за другую базу, Acc.
Выполняем следующие запросы:
ALTER DATABASE Acc
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB (N'Acc', REPAIR_REBUILD) WITH NO_INFOMSGS
GO
Для нее мы получили такой перечень ошибок:
Msg 8978, Level 16, State 1, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data). Page (1:17191) is missing a reference from previous page (1:19106). Possible chain linkage problem.
Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 2
Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data): Page (1:19106) could not be processed. See other errors for details.
The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data), page (1:19106). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 62916617 and -4.
Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data). Page (1:19106) was not seen in the scan although its parent (1:20741) and previous (1:15201) refer to it. Check any previous errors.
Repairing this error requires other errors to be corrected first.
CHECKDB found 0 allocation errors and 4 consistency errors in table 'SC59729' (object ID 1685581043).
CHECKDB found 0 allocation errors and 4 consistency errors in database 'Acc'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Acc, repair_rebuild).
Не забываем вернуть доступ к базе данных:
ALTER DATABASE Acc
SET MULTI_USER;
Для начала запишем скрипты на создание индексов (поочередно):
Затем удаляем индексы:
Затем выполним поочередно скрипты по созданию индексов в открытых окнах, попутно закрывая их (чтобы ничего не забыть).
Все исправили, производим повторную проверку и убеждаемся в отсутствии ошибок.
← →Фокс Йожин ( 2011-10-01 16:59 ) [0]
Есть некая таблица MyTable. При выборке SELECT * FROM MyTable получаю ошибку:
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: недопустимый параметр защиты. Она произошла при прочитать страницы (1:1412094) в базе данных с идентификатором 10 по смещению 0x000002b17fc000 файла "D:\Base \BC1\BC1.mdf". Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.
Вычленить диапазон записей из данной таблицы, которые попадают под ошибку и их удалить?
← →sniknik © ( 2011-10-01 17:08 ) [2]
> SELECT * FROM MyTable
SELECT AnyField FROM MyTable
SELECT AnyButNonBiFirstField FROM MyTable
SELECT TOP 1 * FROM MyTable
SELECT * FROM MyTable WHERE KeyField = 11
дают ошибку?
могут быт противоречивые данные (покоцанные) и типа в ключе дублировались. тогда вычислить и удалить, или скопировать обходя в копию таблицы.
← →Фокс Йожин ( 2011-10-01 17:19 ) [3]
> sniknik © (01.10.11 17:08) [2]
SELECT AnyField FROM MyTable - ошибка
SELECT AnyButNonBiFirstField FROM MyTable - ошибка
SELECT TOP 1 * FROM MyTable - нет ошибки
SELECT * FROM MyTable WHERE KeyField = 11 - нет ошибки
> Ega23 © (01.10.11 17:07) [1]
>
>
DELETE? Попробую, но ведь при выборке этого диапазона возникает ошибка.
Ega23 © ( 2011-10-01 17:37 ) [4]
> Попробую, но ведь при выборке этого диапазона возникает
> ошибка.
Выдели этот диапазон.
Например, таблица, ID c 1 по 1000. Битые записи в диапазоне 439-523.
Найди этот диапазон и удали. Либо перенеси в другую таблицу всё, что лежит вне рамок данного диапазона.
sniknik © ( 2011-10-01 17:54 ) [5]
> этого диапазона возникает ошибка.
> SELECT TOP 1 * FROM MyTable - нет ошибки
> SELECT * FROM MyTable WHERE KeyField = 11 - нет ошибки
есть все чтобы вычислить и удалить. операции > < известны? ну, вперед.
если ошибка будет на удалении, то поможет копирование. т.к. up, есть все чтобы вычислить и . скопировать.
← →sniknik © ( 2011-10-01 17:59 ) [6]
+
операция удаления не обязана читать данные. ей достаточно поставить метку.
а уж после этого DBCC CHECKDB сработает, т.к. не будет заморачиваться целостностью удаленного "мусора".
Фокс Йожин ( 2011-10-01 18:31 ) [7]
> sniknik © (01.10.11 17:54) [5]
>
> есть все чтобы вычислить и удалить. операции > < известны?
> ну, вперед.
>
Дык, ключ не понятно как сгенерён.
Делаю:
select top 9230
* from MyTable
order by ID
выбирает нормально, меняю количество на 9231 - ошибка.
> Дык, ключ не понятно как сгенерён.
это ты непонятно как сгенерён. в школе учился?
сколько всего записей? допустим 1000, + допустим ID автоинкремент и соответствует порядку (для примера сойдет), т.е. первая 1 последняя 1000.
берем половину - 500
select * from MyTable where ID select * from MyTable where ID > 500 работает?
допустим ошибка на втором запросе т.е. теперь первая 501 последняя 1000.
берем половину - 750
select * from MyTable where ID > 500 AND select * from MyTable where ID > 750 работает?
и т.д. рекурсия блин. метод половинного деления.
← →Фокс Йожин ( 2011-10-01 21:21 ) [9]
> сколько всего записей? допустим 1000, + допустим ID автоинкремент
> и соответствует порядку (для примера
1. Первичный ключ - символьный
2. LastKey - это последний ключ в выборке первых неглючных 9230 записей, select top 9230 * from . order by ID,
3. Половинное деление подходит, если глючный диапазон - один, а если внутри него есть живые диапазоны, чередующиеся с глючными?
sniknik © ( 2011-10-01 22:16 ) [10]
> 1. Первичный ключ - символьный
и что? больше, меньше не работает? или половину рассчитать не можешь? ну так это не обязательно должна быть половина, дели по не предопределение количеству. всего то проблем больше итераций будет.
> 2. LastKey - это последний ключ в выборке первых неглючных 9230 записей, select top 9230 * from . order by ID
и что?
с order by и без порядок может быть разный.
> 3. Половинное деление подходит, если глючный диапазон - один, а если внутри него есть живые диапазоны, чередующиеся с глючными?
ну так сделай над собой усилие, и ищи в 2х-3-х диапазонах, в скольких понадобится, до записей.
вообще, тебе нужно восстановить или нет? может ну его нафиг, грохни базу и начни все сначала (символьный на искусственный ключ с автоинкрементом не забудь поменять).
sniknik © ( 2011-10-01 22:26 ) [11]
Можно еще попробовать удалить ключи/индексы. на время.
← →Фокс Йожин ( 2011-10-01 22:44 ) [12]
> sniknik © (01.10.11 22:16) [10]
> ну так это не обязательно должна быть половина, дели по
> не предопределение количеству. всего то проблем больше итераций
> будет.
Ничего не понял. Вот ключи из 16 символов: AAABBBCCCDD . 1345FF,
EEBBCCCDD . AA55C, и т.д. Как перебирать диапазоны?
> и что?
> с order by и без порядок может быть разный.
вычленил диапазон с помощью двух запросов select top N . order by ID и select top M . order by ID desc
Сохранил полученные ID во временную таблицу tmp_MyTable
Делаю delete form MyTable where ID not in (select ID from tmp_MyTable)
Т.е. удаляю все записи, кроме тех, что выбрались без ошибки.
Всё равно падает с ошибкой ввода-вывода.
> вообще, тебе нужно восстановить или нет? может ну его нафиг, грохни базу и начни все сначала (символьный
> на искусственный ключ с автоинкрементом не забудь поменять).
>
>
Нужно. База - 1С:УПП. Так что, ни о каких самодельных автоинкрементах не может быть и речи.
sniknik © ( 2011-10-01 22:58 ) [13]
> перебирать диапазоны?
1 < AA < AAA < EE
и т.д.
> Всё равно падает с ошибкой ввода-вывода.
бл. ну что ты делаешь?
> Делаю delete form MyTable where ID not in (select ID from tmp_MyTable)
> Т.е. удаляю все записи, кроме тех, что выбрались без ошибки.
т.е. условие на перебор и сравнение со ВСЕМИ записям, т.е. чтение тех от которых падает (чтобы сравнить).
delete form MyTable where >
← →Фокс Йожин ( 2011-10-01 23:15 ) [14]
> sniknik © (01.10.11 22:58) [13]
Простой тест:
1. делаю
select
* from MyTable where
Выбирает 1 строчку
2. делаю
select
* from MyTable where ID >= 0xAEB0000E0C3BD80911DC4BE92724F491
and ID падает с ошибкой ввода-вывода.
3. делаю
select
* from MyTable where _IDRRef >= "1" and _IDRRef
падает с ошибкой ввода-вывода.
Т.е., падает вообще всегда, когда задаётся диапазон.
Как же тогда перебирать половинным делением.
← →Фокс Йожин ( 2011-10-01 23:18 ) [15]
select
* from ID where ID between "1" and "1"
Тоже падает с ошибкой ввода-вывода
← →Фокс Йожин ( 2011-10-01 23:19 ) [16]
> Фокс Йожин (01.10.11 23:18) [15]
>
> select
> * from ID where ID between "1" and "1"
>
> Тоже падает с ошибкой ввода-вывода
Пардон:
select
* from MyTable where ID between "1" and "1"
Тоже падает с ошибкой ввода-вывода
← →sniknik © ( 2011-10-01 23:34 ) [17]
> Т.е., падает вообще всегда, когда задаётся диапазон.
с 1 операцией больше, или меньше не падает? этого достаточно чтобы выбрать.
> Как же тогда перебирать половинным делением.
тебе предлагали вариант, а не панацею. что делать и зачем делать (искать глючные и удалить), не ищи как не работает ищи как РАБОТАЕТ. у каждого глюка может быть по своему.
p.s. а вообще сдай базу в контору какую нибудь по восстановлению, а то чую делов натворишь, еще хуже станет.
← →Фокс Йожин ( 2011-10-01 23:45 ) [18]
> sniknik © (01.10.11 23:34) [17]
> с 1 операцией больше, или меньше не падает? этого достаточно
> чтобы выбрать.
падает
> p.s. а вообще сдай базу в контору какую нибудь по восстановлению,
> а то чую делов натворишь, еще хуже станет.
Они там, как правило, месяц держат. Да и не факт, что данные будут восстановлены.
Я, вот, хочу те данные,которые выбираются, сохранить в копию, а глючную таблицу дропнуть. Если после всего этого оборотно-сальдовая ведомость сойдётся, то можно сказать, баг пофиксен.
sniknik © ( 2011-10-01 23:50 ) [19]
> Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий.
?
Фокс Йожин ( 2011-10-01 23:59 ) [20]
> sniknik © (01.10.11 23:50) [19]
пусто
картман © ( 2011-10-02 03:03 ) [21]
попробуй курсором - а вдруг? или че-нть вроде:
declare @key varchar(скока-то там)
select top 1 @key = id from mytable order by id
while true
begin
select top 1
into new_table
from mytable
where id > @key
order by id
select top 1 @key = id from mytable where id>@id order by id
end;
← →Anatoly Podgoretsky © ( 2011-10-02 10:41 ) [22]
> Фокс Йожин (01.10.2011 18:31:07) [7]
reindex сделал?
← →Фокс Йожин ( 2011-10-02 13:20 ) [23]
> картман © (02.10.11 03:03) [21]
пересоздал таблицу из копии, из тех строк, которые выбирались без падения.
> Anatoly Podgoretsky © (02.10.11 10:41) [22]
> reindex сделал?
Сделал. И реструктуризацию тоже. Теперь вот логическую проверку средствами 1С запустил. Жду результата.
Сотрудники компании "АйТи-Консалтинг", специализирующиеся на разных программных продуктах, бухгалтерских и it услугах, написали статьи, позволяющие посетителям сайта быстро ориентироваться в ответах на интересующие вопросы.
Неточности СУБД базы данных (ошибка SQL) в программном продукте 1С: Предприятие 8
Данный материал будет полезен пользователям, столкнувшимся с неточностями в работе программных продуктов на платформе 1С: Предприятие 8.
На рисунке 1 приведен пример окна ошибки: Ошибка СУБД Ошибка SQL.
Почему возникают такие ошибки?
В первую очередь это обуславливается неправильной работой пользователей на местах с программами 1С. Экономия владельцев бизнеса на обучении своего персонала корректной работе с данным программным обеспечением, либо экономия на техническом оснащении, работа на устаревших компьютерах, применение близких к окончанию сроков эксплуатации жестких дисков через некоторое время могут вызвать крупные расходы. Неприятным результатом может стать простой бизнеса, а также утеря данных управленческого, бухгалтерского либо финансового учета.
Примеры источников ошибок в функционировании программ 1С и виды визуального выражения нарушения целостности БД (база данных):
аварийное завершение работы ОС с работающей программой 1С: Предприятие 8, в особенности во время формирования, проведения либо удаления файлов;
удаление и повреждение конфигурационных файлов в результате вмешательства со стороны пользователя либо техники;
приостановка процесса восстановления архивной информации;
отсутствие внешнего надежного напряжения питания;
присутствие файлов без нумерации, дат создания;
присутствие файлов с датой создания, которая не соответствует рядом стоящим файлам, к примеру, 2001 г. 01 ч. 01 мин. 01 с.;
присутствие операций без нумерации, дат создания;
недоступность ранее созданных файлов и операций;
отсутствие ссылок на объекты.
Таким образом, в первую очередь нужно завершить работу программы 1С.
После этого создайте копию БД (база данных) с повреждениями (для этого нужно сохранить базу в отдельный каталог на винчестере). Путь, ведущий к местонахождению БД (база данных), можно определить с помощью панели запуска 1С: Предприятие 8 внизу, найдите данный каталог на жестком диске и скопируйте его (смотрите рисунок 2).
Рисунок 2: Окно запуска 1С: Предприятие 8.
Далее протестируйте БД (база данных) на физическую целостность (на предмет «разрушения»). Чтобы это сделать, выполните переход к стандартной встроенной обработке 1С: Предприятие 8 по исправлению и тестированию неточностей – chdbfl.exe (загрузить для 1С: Предприятие 8). Данный документ должен присутствовать в каталоге с установленной программой 1С, найдите и выполните его запуск (смотрите рисунок 3).
Рисунок 3: Местонахождение документа chdbfl.exe.
Потом выбираем документ 1CV8.1 CD, который можно найти в каталоге нашей БД (база данных) с повреждениями, устанавливаем галочку «Исправлять обнаруженные ошибки» и жмем «Выполнить» (смотрите рисунок 4).
На проверку физической целостности документа БД (база данных) может уйти от 10 мин. до нескольких часов – это определяется объемом вашей БД (база данных) и количеством неточностей в ней. По завершении проверки обнаруженные неточности рекомендуется сохранить в отдельный документ для последующей экспертной диагностики.
Рисунок 4: Окно проверки физической целостности документа информационной базы
После этого зайдите в режим конфигуратора (смотрите рисунок 5) и найдите в нем сервисную утилиту “Тестирование и исправление информационной базы” (смотрите рисунок 6).
Меню – Администрирование – Тестирование и исправление
Рисунок 5: Конфигуратор
Рисунок 6: Окно тестирования и исправления БД (база данных)
Выберите такие пункты, как:
Реиндексация таблиц информационной базы – функция восстановления табличной части БД (база данных).
Проверка логической целостности информационной базы – функция проверки логической целостности БД (база данных).
Проверка ссылочной целостности информационной базы – тестирование внутренних связей таблиц, которые устанавливает программа 1С: Предприятие 8, проверка фактического существования элементов данных со ссылками в полях записи таблиц.
Перерасчет итогов – выполнение полного перерасчета итоговых данных.
Переключатель ниже, выбор пункта «Тестирование и исправление».
Операция «Тестирование и исправление» может длиться от 10 мин. до нескольких часов – это определяется объемом БД (база данных) и количеством неточностей в ней. По завершении проверки обнаруженные неточности рекомендуется сохранить в отдельный документ для последующей экспертной диагностики.
На следующем этапе закройте конфигуратор, откройте БД (база данных) в стандартном режиме и оцените произошедшие изменения с поврежденными файлами либо справочниками, сформируйте ключевые отчеты для сравнения. Если проблемы отсутствуют и все в порядке, смело продолжайте работу с БД (база данных). Если проблема с информационной базой все еще присутствует, приглашайте эксперта по 1С из обслуживающей компании «АйТи-Консалтинг», либо сразу обращайтесь в техническую поддержку 1С.
Внимательно изучите ситуацию, сделайте верные выводы: обеспечьте вашим работникам обучение корректной работе с программами 1С, купите новую технику на замену старой.
Если Вы слишком заняты и не можете тратить на это время, мы ждем Ваших обращений в сертифицированный центр обслуживания 1С - «АйТи-Консалтинг».
Читайте также: