|
dbexport
|
|||
---|---|---|---|
#18+
Добрый день. Win 7, ids 9.40 Делаю бэкап базы dbexport db_damp -ss Разворачиваю на новом сервере dbimport -q db_damp -d dbdbs Проблема: На новом сервере таблицы создаются, данные загружаются, но При построении индексов получаю ошибку 100-ISAM error: duplicate value for a record with unique key. На новом сервере смотрю таблицу на которой произошла ошибка, в таблице присутствует две записи с уникальным ключом.(в файле скрипта так же вижу две записи) На сервере, где был выполнен dbexport, в таблице нет этой дублирующийся записи(есть только одна запись). Не пойму от куда dbexport берёт эту дублирующуюся запись, причем запись в таблице не полностью совпадает с записью оригинала только поля по которым построен индекс. Заранее спасибо за советы. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2019, 09:12 |
|
dbexport
|
|||
---|---|---|---|
#18+
Конечно же на новом сервере не будет двух записей т.к. при загрузке произошла ошибка и вторая запись не была загружена. в файле database_name.sql закоментарьте двумя минусами строку с созданием уникального ограничения (и если есть уникального индекса) тогда сможете загрузить данные в таблицу. Потом руками вычищайте данные и создавайте уникальные индексы и/или ограничения ... |
|||
:
Нравится:
Не нравится:
|
|||
16.01.2019, 18:31 |
|
dbexport
|
|||
---|---|---|---|
#18+
cprКонечно же на новом сервере не будет двух записей я же написал что timtimНа новом сервере смотрю таблицу на которой произошла ошибка, в таблице присутствует две записи с уникальным ключом меня интересует от куда берется "задвоенная" запись. на сервере-источнике нет задвоения. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2019, 07:46 |
|
dbexport
|
|||
---|---|---|---|
#18+
timtimcprКонечно же на новом сервере не будет двух записей я же написал что timtimНа новом сервере смотрю таблицу на которой произошла ошибка, в таблице присутствует две записи с уникальным ключом меня интересует от куда берется "задвоенная" запись. на сервере-источнике нет задвоения. если на источнике пересоздать таблицу (с перезагрузкой данных ) - запись появится , лечить таблицу ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2019, 09:09 |
|
dbexport
|
|||
---|---|---|---|
#18+
aist-pskесли на источнике пересоздать таблицу (с перезагрузкой данных ) - запись появится , лечить таблицу в файлах, которые создал dbexport, видно дублирующуюся запись, а в таблице сервера источника нет этой дублирующейся записи Каким образом может появится дублирующаяся запись в файле dbeport-а если её нет в таблице, вот в чем вопрос. От куда dbexport вытягивает эту запись если её нет в таблице? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2019, 09:31 |
|
dbexport
|
|||
---|---|---|---|
#18+
А ві попробуйте на источнике вібрать запись через seq. scan таблицы а не через индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2019, 09:43 |
|
dbexport
|
|||
---|---|---|---|
#18+
aist-pskесли на источнике пересоздать таблицу (с перезагрузкой данных ) - запись появится , лечить таблицу Запись появилась. А как лечить таблицу если в ней я не вижу(до выгрузки/загрузки) неправильной записи? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2019, 08:33 |
|
dbexport
|
|||
---|---|---|---|
#18+
утилита oncheck для проверки https://www.ibm.com/support/knowledgecenter/ru/SSGU8G_12.1.0/com.ibm.adref.doc/ids_adr_0369.htm самое простое , если позволяет время - пересоздать таблицу (с перезагрузкой данных) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2019, 15:15 |
|
dbexport
|
|||
---|---|---|---|
#18+
aist-pskпересоздать таблицу (с перезагрузкой данных) Таблиц под сотню будет. А oncheck какие опасности таит? Попробую для начала oncheck -c по всем ключам. Shared memory ещё шалит на сервере, надо buffers уменьшить, перезагрузить. И это асе на prod)) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2019, 18:44 |
|
dbexport
|
|||
---|---|---|---|
#18+
timtim, если onheck использовать только для вывода отчета, то ничем не грозит. Для починки индексов например oncheck не рекомендуется (во всяком случае для старых версий) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 09:27 |
|
dbexport
|
|||
---|---|---|---|
#18+
cprДля починки индексов например oncheck не рекомендуетс Понял, спасибо за инфу. Нашел с десяток битых индексов. Все пересоздал кроме одного. Дропаю индекс - в ответ получаю что индекс дропнут, но смотрю через eSQlEditor и вижу что на месте дропнутого индекса появился другой индекс но с числовым названием 231_49 и по тем же столбцам. Пытаюсь дропнуть этот "числовой индекс", а он не дропается. Почему создается этот "числовой индекс" после drop index? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 10:36 |
|
dbexport
|
|||
---|---|---|---|
#18+
timtimна месте дропнутого индекса появился другой индекс но с числовым названием как понял это автоиндекс создаётся, но почему на других таблицах он не создается хотя в них тоже есть констрейны ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 11:07 |
|
dbexport
|
|||
---|---|---|---|
#18+
timtimtimtimна месте дропнутого индекса появился другой индекс но с числовым названием как понял это автоиндекс создаётся, но почему на других таблицах он не создается хотя в них тоже есть констрейны Констрейнт навешивается на индекс, т.е. он не может существовать вне индекса. Поэтому, когда дропается именованный индекс, на который создано ограничение, он (индекс) пересоздается автоматом. На выходе автоиндекс. Что бы этого избежать, надо вначале дропнуть констрейнт (ограничитель), а затем уже индекс (или автоиндекс). Соответственно, что бы пересоздать: 1. Дропаем констрент 2. Дропаем индекс 3. Создаем индекс 4. Создаем констрейнт. Как-то так... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 11:36 |
|
dbexport
|
|||
---|---|---|---|
#18+
timtimно почему на других таблицах он не создается хотя в них тоже есть констрейны Не на каждый существующий индекс может ссылаться констрент. Для этого надо анализировать структуру БД что бы понять на какой индекс или автоиндекс ссылается констрент. А так, в таблице может быть введено ограничение, но она может содержать и просто индексы на которые не цепляется констрент. Как-то так... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 11:39 |
|
dbexport
|
|||
---|---|---|---|
#18+
vvt11. Дропаем констрент 2. Дропаем индекс 3. Создаем индекс 4. Создаем констрейнт. Так и сделал. В той таблице был индекс по полям аналогичным констрейнту. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 11:43 |
|
dbexport
|
|||
---|---|---|---|
#18+
timtimВ той таблице был индекс по полям аналогичным констрейнту. и я правильно понимаю что для данной таблицы не нужен констрейнт т.к. есть unique index? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 12:49 |
|
dbexport
|
|||
---|---|---|---|
#18+
timtim, если не надо создавать ссылку на таблицу, то можно первичный ключ не создавать. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 15:46 |
|
dbexport
|
|||
---|---|---|---|
#18+
timtimtimtimВ той таблице был индекс по полям аналогичным констрейнту. и я правильно понимаю что для данной таблицы не нужен констрейнт т.к. есть unique index? Вопрос сложный для меня. И UNIQUE INDEX и CONSTRAINT UNIQUE вводят ограничение на уникальность данных в поле. Если у нас индексировано одно поле как уникальное, на него можно навесить CONSTRAINT UNIQUE чисто технически, это не противоречит конструкции. Но, есть и другие случаи, например, на UNIQUE INDEX навесить CONSTRAINT PRIMARY KEY, почему бы и нет? И, с другой стороны, ни что не запрещает создать CONSTRAINT UNIQUE на два проиндексированных поля, одно из которых может быть UNIQUE INDEX. Тут, скорее всего от задач зависит, которыми руководствуется разработчик БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2019, 15:46 |
|
|
start [/forum/topic.php?fid=44&msg=39763326&tid=1606719]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
406ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 337ms |
total: | 852ms |
0 / 0 |