Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
select double records
|
|||
|---|---|---|---|
|
#18+
всем привет! около 2 дней не могу обмануть оптимизатор задача - выбрать дублирующиеся записи из таблицы для дальнейшей обработки, что удалить, что отредактировать... в таблице около 2 миллионов записей около 200 000 дублей запрос Код: plaintext 1. 2. 3. по полю CARD_NUMBER - естественно существует индекс сначала попробовал самым неэффективным вариантом, через подзапрос с IN Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. затем попробовал несколько вариантов через объединение таблиц Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. решил попытаться через временные таблицы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ощущение такое, что оптимизатор "теряет" индекс и делает выборку через полный перебор таблицы на своем сервере с IB эту задачу решил бы через вложенный FOR, на птичке тоже слетает оптимизатор, когда пытался сделать JOIN с подселектом группировки Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. что же делать в подобной ситуации ? из неперепробованного - построение индекса по временной таблице... :) или использование конструкции FOR, но опыта с дб2 практически никакого ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2009, 07:31 |
|
||
|
select double records
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Если вам любую запись из дублей по CARD_NUMBER надо выбрать, то Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2009, 09:57 |
|
||
|
select double records
|
|||
|---|---|---|---|
|
#18+
спасибо, Mark! буду в курсе, что так можно сделать нужны все записи дублей, чтобы понять, какую из них можно удалить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2009, 11:12 |
|
||
|
select double records
|
|||
|---|---|---|---|
|
#18+
jack_nskнужны все записи дублей, чтобы понять, какую из них можно удалить Ну, тогда либо Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2009, 11:21 |
|
||
|
select double records
|
|||
|---|---|---|---|
|
#18+
длительность выполнения запроса - 42 минуты... стабильно! :) версия Express-C LUW можно конечно предположить, что размер запроса слишком велик для явы, на которой написан Дата Студия... можно сделать поправку на то, что селект работает на вью, которые построены на лотусовых таблицах, среплицированных в дб2... оппробую ещё процедуру поправить, чтобы проиндексировать временную таблицу после её заполнения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2009, 12:26 |
|
||
|
select double records
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. не смертельно, но любопытство гложет - в каком месте спотыкается оптимизатор ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2009, 13:37 |
|
||
|
select double records
|
|||
|---|---|---|---|
|
#18+
jack_nsk Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. не смертельно, но любопытство гложет - в каком месте спотыкается оптимизатор ? 0. Соберите статистику на таблицу и её индексы: call sysproc.admin_cmd('runstats on DISCOUNT.DB2_PERSON and indexes all') 1. У вас какого типа поле CARD_NUMBER? Т.е. зачем вы приведение типов для групп делаете? 2. P1: BEGIN DECLARE stmt varchar(128); DECLARE cursor2... ... CREATE UNIQUE INDEX session.... SET stmt = 'runstats on table session.double_ids and indexes all'; call sysproc.admin_cmd(stmt); open cursor2; END 3. Зачем "session.double_ids left join DISCOUNT.DB2_PERSON"? Какой в этом смысл? 4. Приведите план запроса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2009, 14:02 |
|
||
|
select double records
|
|||
|---|---|---|---|
|
#18+
Марк, спасибо! ваши ответы заставили задуматься первым делом пришлось осознать, что дб2 в части оптимизации плана выполнения запроса работает иначе, чем привычная мне птичка. полистал форум, нашел ссылку LEO: самонастраивающийся оптимизатор запросов для DB2 , которая много чего объяснила... особенно то, что "от перемены мест слагаемых" мало что зависит - оптимизатор сам построит план запроса исходя из статистики но похоже я нашел на ссылке некое указание на причину, относительно которой не получается получить быстрый запрос Поскольку большая часть агрегатных функций может вычисляться в инкрементальном режиме, по мере сортировки строк, в своем окончательном виде TEMP будет содержать результат выполнения раздела GROUP BY. Оптимальный алгоритм соединения (соединение методом вложенных циклов, соединение через хеширование или соединение слиянием) для последующего соединения Orders и Products критически зависит от размера результата GROUP BY. Оптимизатор запросов может выбрать неоптимальный алгоритм слияния при переоценке или недооценке размера этого результата. т.к. 10% дублирующихся записей в таблице - это явное безобразие, в нормально спроектированном приложении такого не должно быть, то я сократил количество возвращаемых записей в подзапросе получения дублирующихся номеров карт Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. в реальности мало кто может работать над выборкой в 200 000 записей, поэтому запросы можно разнести на диапазоны номеров карт, но это уже не моя забота... :) в центральном офисе вручную через интерфейс лотуса редактируют дубли карт, моя задача только передать список карт моего региона Mark Barinstein 0. Соберите статистику на таблицу и её индексы: call sysproc.admin_cmd('runstats on DISCOUNT.DB2_PERSON and indexes all') в дата студии не получилось выполнить запрос, но я выполнил сбор статистики в контроль центре, правда результаты сбора статистики контроль центр не выдал Mark Barinstein 1. У вас какого типа поле CARD_NUMBER? Т.е. зачем вы приведение типов для групп делаете? в реальности тип CARD_NUMBER - double по моим смутным ощущениям индекс - это целочисленное значение, поэтому пробовал привести результат к целочисленному типу Mark Barinstein 2. P1: BEGIN DECLARE stmt varchar(128); DECLARE cursor2... ... CREATE UNIQUE INDEX session.... SET stmt = 'runstats on table session.double_ids and indexes all'; call sysproc.admin_cmd(stmt); open cursor2; END из любопытства обязательно попробую Mark Barinstein 3. Зачем "session.double_ids left join DISCOUNT.DB2_PERSON"? Какой в этом смысл? по моему опыту иногда внутренний join работает медленнее, чем left join left join указывает оптимизатору с какой таблицы начинать выборку, а join - декартово произведение таблиц, но это справедливо только для моего опыта в пределах FB Mark Barinstein 4. Приведите план запроса к сожалению не нашел сходу в контроль центре, как план запроса в текстовом виде получить... прикладываю картинку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2009, 07:16 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=35993070&tid=1603249]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
224ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 322ms |

| 0 / 0 |
