Галактика в вопросах и ответах

Добрый день!
Помогите пожалуйста, в процессе конвертации БД 7.11 -> 7.12 все виснет намертво:
- Процесс W3DBSMGR.EXE захватывает 100% ресурсов ЦП.
- Обращение к винчестеру прекращается (индикатор тухнет).
- Последнее, что вижу в строке запуска Dicom.bat: ALTER.LOT(2378)
И все...

Уже сегодня распаковал себе чистую систему (Win2000prof). Поставил с нуля обе Галактики (7.11 и 7.12) серверные. Запустил процесс конвертации на тестовой БД из поставки 7.11 - все нормально сконвертнулось минут за 10-15.
Начал делать реальную БД - виснет опять часа через три на вышеописанном и все... Причем, насколько помню виснет не только на ALTER.LOT(2378), а на и на других ALTER.LOT(xxx), каких точно не помню...
Подскажите пожалуйста, как быть...

1. то что виснет это не факт.
если табла большая то процесс могет занять какое то время(у меня было 6 часов как то)
2. теперь как бороться
сначала убедиться что зависло
открываете alter каким нибудь нормальным текстовым редоктором( хоть через галку) ищете там эту строку
смотрите какая табла модифицируеться в это время( счетчик врет на строку)
ищите сей файл, смотрите когда он последний раз менялся.
если больше часа то это подозрительно - первасив раз минут в 10 сбрасывает кэш.
3. Можно чуток подправить конвертор
до вывозова alter
сделать выгрузку в дбф, грохнуть таблу( ну я делал drop table - но вам наверное проще будет физически удалить файл)
после отработки alter загрузить таблу обратно.
естественно свои включения делаете не в alter, а добавляете вывозы в dicom.bat

Да, Вы правы, наткнулись на большую таблицу: CATALOGS - около 1ГБ и по ней индекс строится - вот и виснет...

Alter Table CATALOGS
Add Index (CATHOST= CREF3)
;

Мне техподдержка, как и Вы, посоветовала выгрузить эту таблицу в DBF, но не убивать потом таблицу, а убить в ней только записи, относящиеся к Административно-территориальному делению - их там подавляющее большинство. Сказали не убивать полностью таблицу, т.к. она системная, без нее конвертация нормально не пройдет. Фокус с подпихиванием чистой таблицы, заново построенной по словарю сказали тоже не пройдет - надо однозначно убивать записи АТД.

Вот не могу написать запрос на удаление никак.

В таблице этой у записей АТД поле 'mainlink' ссылается на элемент справочника где syscode равен отрицательному числу (-10) - вот этот элемент справочника и называется 'АТД' (у него syscode= -10). У ссылающихся на него записей, которые надо удалить syscode=0. Причем саму запись 'АТД' убивать нельзя (у нее mainlink = nrec).

Нужно написать что-то типа:

delete from catalogs where
(( comp(0000000000000221h) [нрек АТД] /== mainlink
AND syscode=0
));

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

ну вы попали
все записи тоже как то нельзя очишать, поскоку у вас полетят адреса сотрудников.
индекс есть
LPR+mainlink
по хорошему нужно бы отобрать все записи с учетом иерархии не которые есть ссылки в address.city
( address.city == catalogs.nrec and
catalogs.cparent == cat1.nrec and
cat1.cparent == cat2.nrec and
....
cat????.cparent == cat_end.mainlink )
такие записи убирать нельзя !!!!.
не знаю насколько вы обойдетесь только sql.
в принципе нужно сначала пометить те что нужно оставить а потом удалить то чего не нужно. например в имя добавить '!' или в другое поле.
тогда удаление пишем например так
delete catalogs where (( 0 == lpr and
???????? == mainlink )) and (syscode<>-10 and susbtr(name,1,1)<>'!') ;
и никогда более не качайте российский кладр - лишнее все это.
по каждой области есть свой.
а вообще продолжайте теребить техподдержку , пусть дают готовое решение.

Да, что же это за конвертор Топ Софт выпустил, если такие запарки возникают при конвертации...

У нас CATALOGS около 8 часов конвертился, советую просто подождать...

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

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

Delete From Catalogs
Where
((
0 /== lpr and
comp(0000000000000221h) /== MainLink
)) and syscode=0;

Утром встал, все то же: 'Произвожу модификацию данных...'. В растроенных чувствах вырубил комп... Где-то около 8 часов комп работал. Потом прочитал тут, что это вроде как и нормально - седня поставлю еще раз на ночь этот запрос.
Запрос SELECT при той же секции WHERE делается примерно пол-часа. Причем, что я обнаружил - полно - штук по 7-10 записей с одинаковым содержимым поля Name. Это из-за чего так не знаете?

...А на работе перед уходом вчера поставил конвертиться - сегодня до сих пор делает ту же таблицу CATALOGS.

2 edward_K: Вы писали:
>> '...Смотрите какая табла модифицируеться в это время (счетчик врет на строку) ищите сей файл, смотрите когда он последний раз менялся. Если больше часа то это подозрительно - первасив раз минут в 10 сбрасывает кэш.

Сегодня (25 августа 2005 / 11:30) посмотрел принтскрин со свойств файла CATALOGS.DAT:
- Создан: 24 августа 2005г. - 17:23 - это я скопировал примерно в это время вчера тестовую БД и запустил конвертацию. Тут все верно я думаю.
- Изменен: 24 августа 2005г. - 18:57 - это я думаю в это время до CATALOGS.DAT добрался конвертер, начал его изменять и повис... И дата осталась та же - вы это имели ввиду в своем посте?
- Открыт: 25 августа 2005г. - 11:07 - это сегодня с утра посмотрели свойства этого файла.

Второй админ думает, что процесс не висит, а работает - говорит, что меняется процент загрузки проца 96-99% И еще винт чего-то пишет периодически...
В общем посмотрим...

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

Алексей писал(а): Терпение брат, терпение...

... и щетина превратится в золото.

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

Висяк... это со среды, а сегодня - понедельник...
Да, там есть такие цифры: если смотреть active users: 'Records Read', 'Records Inserted', 'Records Deleted', 'Records Updated' - все не меняются...

2 Nick
Вот вам сдался этот запрос:)
Запускаете Галактику, переходите в управление персоналом, а далее Настройка\Каталоги\Удаление каталогов. Выбираете АТД и жмете кнопку "Удалить". Кстати, это необходимо сделать всем, кто перешел на Галактику 7.12, т.к. этот каталог в 7.12 не используется и является просто мусором, тормозящим работу с каталогами. Его нужно было удалять при конвертации, но разработчики как всегда лопухнулись:-(
Если удаление зависает, то возможно в иерархии образовалась циклическая ссылка. В этом случае можно либо запустить проверку каталогов (есть в меню управления персоналом), либо удалить в SUPPORT запросом такого вида:

Delete From Catalogs
Where
(
lpr = integer(0) and
MainLink = comp(0000000000000221h) and
code <> ''
);

Оставшиеся записи можно добить уже вашим запросом.

Delete From Catalogs
Where
(
lpr = integer(0) and
MainLink = comp(0000000000000221h) and
syscode = 0
);

Если все равно удаление производиться непозволительно долго, то выгружаем в DBF все кроме АТД с помощью select * from catalogs where (mainlink<>comp(0000000000000221h)) to dbf, затем физическое удаление файла Catalogs, затем загрузка из DBF в Catalogs.
Все вышесказанное надо предварительно проверить на копии БД.

2 edward_K
Можно конечно грузить только KLADR Воронежской области, а затем мучиться с людьми, прописанными не в нашей области. Если бы разработчики сразу бы додумались, что Catalogs не лучшее место для АТД, то таких проблем просто не возникло бы.

Всем большое спасибо за помощь! Делали так, как сказал WiRuc:

1) select * from catalogs where (comp(0000000000000221h) <> mainlink) to dbf d:\noATD1.dbf;
Это все что не АТД мы сохраняем в DBF.

2) select * from catalogs where (nrec=comp(0000000000000221h)) to dbf d:\noATD2.dbf;
Это саму запись 'АТД' мы сохраняем в DBF (нужна при конверте).

3) select * from catalogs to dbf d:\Catalogs.dbf;
Мы сохраняем всю таблицу CATALOGS в DBF, чтобы не потерять АТД. После конвертации удалим файл таблицы CATALOGS и импортируем всю таблицу CATALOGS из Catalogs.dbf.

4) Удаление физического файла таблицы Catalogs (CATALOGS.DAT) - для выполнения конверта без АТД.

5) import Catalogs from dbf d:\noATD1.dbf;
Это все что не АТД мы восстанавливаем из DBF в CATALOGS - для проведения конвертации.

6) import Catalogs from dbf d:\noATD2.dbf;
Это саму запись 'АТД' мы восстанавливаем из DBF в CATALOGS - для проведения конвертации.

7) Собственно конвертация с модифицированной таблицей Catalogs.

Конвертация проходит при таком способе довольно таки быстро - около 3-х часов. Все без ошибок, но потом есть проблема с восстановлением Catalogs. После конверта, для того, чтобы не потерять АТД я убиваю в конвертированной БД файл Catalogs.dat и импортирую таблицу полностью из Catalogs.dbf, сделанной на пункте N3. Импорт проходит успешно, но потом начинается построение индекса по импортированной таблице и тут облом - Галактика пишет что-то вроде '...Дублированное значение при уникальном ключе в таблице...' и конвертация заканчивается неудачно...
Как это можно обойти не подскажите ???