Bug 9449

Выгрузил в zip, загрузил в postgres. Прошло нормально, но на этапе (после загрузки) пересчет ссылок по графе ВРН падает в разных местах. 
Решил провести тестирование и исправление еще в dbf, но это на долго подвисло. Но что-то происходит.

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

Аналог screen для Иксов называется xpra.
Отключение синка: /etc/wine/config: export WINEDISABLEFLUSH=yes
Базу данных стоит расположить на разделе, смонтированном с tmpfs (на builder* такого нет, но наверное /tmp тоже сойдёт).

Сделал с горем пополам тестирование и исправление. На наших машинах делалось часов 6.
Выгрузил. Думаю, что сейчас зальется нормально.

Нормально не залилось. В dbf были дублирующиеся записи, которые не обнаружились при тестировании и исправлении

Вот какие я получил ощибки.

ERROR:  could not create unique index "idd_sc26391"
DETAIL:  Table contains duplicated values.
CONTEXT:  SQL statement "CREATE UNIQUE INDEX "idd_sc26391" ON "sc26391" ("id");
        INSERT INTO pg_indexes_name VALUES('IDD','"sc26391"','"idd_sc26391"')"
        PL/pgSQL function "exec_query" line 8 at EXECUTE statement
STATEMENT:  SELECT CASE WHEN NOT EXISTS (SELECT * FROM "sysindexes" WHERE "name" = 'IDD' AND "id" = "object_id"('SC26391')) TH
        exec_query('CREATE UNIQUE INDEX "idd_sc26391" ON "sc26391" ("id");
        INSERT INTO pg_indexes_name VALUES(''IDD'',''"sc26391"'',''"idd_sc26391"'')')
        END
        
        
        
ERROR:  could not create unique index "idd_sc29109"
DETAIL:  Table contains duplicated values.
CONTEXT:  SQL statement "CREATE UNIQUE INDEX "idd_sc29109" ON "sc29109" ("id");
        INSERT INTO pg_indexes_name VALUES('IDD','"sc29109"','"idd_sc29109"')"
        PL/pgSQL function "exec_query" line 8 at EXECUTE statement
STATEMENT:  SELECT CASE WHEN NOT EXISTS (SELECT * FROM "sysindexes" WHERE "name" = 'IDD' AND "id" = "object_id"('SC29109')) TH
        exec_query('CREATE UNIQUE INDEX "idd_sc29109" ON "sc29109" ("id");
        INSERT INTO pg_indexes_name VALUES(''IDD'',''"sc29109"'',''"idd_sc29109"'')')
        END

Постарался, как мог исправить (удалил дубли):


SELECT count(id), id FROM sc26391 GROUP BY id HAVING count(id) > 1 ;
 count |    id     
-------+-----------
     2 |    ACK   
(1 row)

SELECT row_id, id FROM sc26391 WHERE id LIKe '%ACK%';
 row_id |    id     
--------+-----------
  32515 |    ACK   
  32516 |    ACK   
(2 rows)

DELETE FROM sc26391 WHERE row_id = 32516;

SELECT count(id), id FROM sc29109 GROUP BY id HAVING count(id) > 1 ;
 count |    id     
-------+-----------
     2 |      2   
     2 |      1   
(2 rows)

Долго мучился в итоге удалил дублирующиеся записи из dbf.
Интересно, что не заливается в MS SQL, похоже из-за неправильно написанной конфигурации. 
В postgres этой ошибки нету, зато есть другая "the query is NULL". Это ошибка выдается odbc драйвером и ей можно игнорировать, по скольку она не критическая. Хотя можно и разобраться, почему так происходит.

Created attachment 2961 [details]
Скриншот ошибки в MS SQL

При заливки в MS SQL происходит ошибка на этапе 
"Пересчет ссылок по графе отбора 'ДокВид'"
Думаю, что это из-за неправильно написанной конфигурации.

Created attachment 2962 [details]
Промахнулся. Вот правильный скриншот.

Дело не в ошибке NULL query. Падает всё равно bad_alloc, всё время в разных местах. Надо попробывать из win.

Падает, как я ни пробовал. Но вот, что я заметил падает на этапе "тестирование и исправление", на сколько я понимаю, именно это происходит после загрузки, но надо проконсультироваться. 
И надо протестировать потыкать по кнопкам, одинаковые ли документы.

К сожалению, предположение оказалось не верным. Пересчет ссылок и итогов всё равно нужно запустить. Запустил, падает на том же месте. 
Мне подсказали, что можно удалить старые документы (там есть за 18 век), тогда не будет там много пересчитываться. Надо попробывать, может это улучшит ситуацию

(В ответ на comment #9)
> Дело не в ошибке NULL query. Падает всё равно bad_alloc, всё время в разных
> местах. Надо попробывать из win.
Хорошо бы иметь какую-то отладочную версию, и если это опять ошибка с работой с памятью в трансляторе, то что-то продвинуть в этом направлении, по сравнению с прошлыми попытками отладки.
У нас вот появилось чудо средство для отладки проблем с памятью для Linux с помощью LLVM. Что-то типа http://clang.llvm.org/docs/AddressSanitizer.html

После того, как убрали старые (до 20 века) документы, стало загружаться и после того момента. Но там то память кончитась, то место, сейчас поставил загружаться, надеюсь к завтрашнему дню будет готово. 
Тут брат у меня залил в ms sql исправив какие-то ошибки в базе 1с, может придется воспользоваться его вариантом. Но он каких-то денег хочет. Посмотрим.

Подготовил к отправке. По пути выяснилось, что в нашем postgre сломалась база при падении из-за отклучноого sync'а
Залил в новую в pg 9.1.9

Что им нужно знать. 
Postgre@Etersoft мы рекомендуем 9.1.9. 
файлы лежат в 
ftp://ftp.etersoft.ru/pub/people/stas/binar/W0QVLQD3FO.
Состав файлов
a1c277.tar.gz  -- дамп базы pg
from1c277sql.zip  -- файлы 1с (просто нужно разорхивировать и в режиме конструктора изменить параметры подключения к postgre)
report1canalyze.zip -- отчет об ошибках в базе 1с. Мы их можем исправить, если они хотят.

Первый раз, возможно нужно запустить 1с в монопольном режиме

Для того, что бы загрузить пришлось удалить несколько документов до 20 века, и пару начала 20 века
База в теперешнем состоянии всё равно не загружается в mssql. Загружается только с исправленными ошибками о которых говорится в отчете.

Добавление
Из двух таблиц были удалены записи с дублирующимеся записями. Это
sc26391
id = ACK 
2 записи
sc29109
id = 1
id = 2
по 2 записи

Желательно, что бы они это бы сделали без нас.

(В ответ на comment #14)
> Подготовил к отправке. По пути выяснилось, что в нашем postgre сломалась база
> при падении из-за отклучноого sync'а
Мне было бы интересно узнать, как отключение sync может приводить к порче базы при падении программы. Пока выглядит абсурдно.

Но если это каким-то образом так, предлагаю запускать postgres командой
# eatmydata serv postgresql start
Это точно отключит все синки и никак при этом на логику программы не повлияет.

(В ответ на comment #16)
> Мне было бы интересно узнать, как отключение sync может приводить к порче базы
> при падении программы. Пока выглядит абсурдно.
http://www.postgresql.org/docs/current/static/runtime-config-wal.html
While turning off fsync is often a performance benefit, this can result in unrecoverable data corruption in the event of a power failure or system crash. 
Тут достаточно чётко написало. "data corruption"
Может и обсурдно, но это случилось.

> Но если это каким-то образом так, предлагаю запускать postgres командой
> # eatmydata serv postgresql start
> Это точно отключит все синки и никак при этом на логику программы не повлияет.
Хорошо, буду запускать так.

Стас, что тебе необходимо из железа, для поднятия стенда с базой?

Сложный вопрос. Мне кажется, что если они собираются покупать, то вменяемым будет машина с 4-8 Гб памяти, средним современный процессором, и не плохо бы ssd под базу. Это под postgres.
Но неизвестно сколько у них там собирается быть пользователей. И как они всё это используют -- от этого много зависит.

Я думаю, что сначала им бы посмотреть на работоспособность, а там уже и быстродействие тестировать
(В ответ на comment #21)
> Стас, что тебе необходимо из железа, для поднятия стенда с базой?

Подготовил всё для быстрого перехода на тестовый сервер.

Сделал дампы базы, всё заархивировал.
Лежит в /var/ftp/tmp/stas/2binar/