бАльшие зАпросы

Столкнулся с проблемой выборки данных из очень большой таблицы. Одна то была невеликая, около полумиллиона записей, а вот вторая раз в 100 поболее. Проблема ослажнялась тем, что таблицы эти временные, т.е. никаких индексов и уже тем более статистик у них нету. А выборка подразумевала их обьединие (JOIN) по определённым полям, плюс фильтр по дате. Гениальное решение, построить побыстренькому индексы привело к тому, что после 4х часов ожидания Oracle с бодрым видом заявлял "Стрижка только начата". Время конечно даром не пропало и множество дел малых и великих было переделано. Однако понедельник подходил к своему логическому концу, и данные пора было уже как-то вытаскивать. Поговорив с админом, данные восстанавливавшим, я узанал, что оных там около 35 Гб. Вдохновившись сей новостью, пошёл на поклон к DBA гуру. От него узнал много новых слов, типа "NOLOGGING" и "PARALLEL", а также его мнение про людей их не использующих при создании индексов. По ходу дела выяснилось, что построить индексы для моей беды гороздо дороже (дольше), чем тупо сделать hash-join двух таблиц. Ибо full scan он полюбому будет быстрее, чем он же + order by (построение индекса), а затем ещё index join (выборка) :) Осталась только проблема со статистиками для таблиц, но эта беда, не беда и во главе запроса появился HINT вида USE_HASH(tbl_a tbl_b) LEADING( tbl_a ). Естественно tbl_a - меньшая таблица. Также был дан наказ мониторить процесс путём опроса специализированного VIEW - v$session_longops, отфильтровав ненужное указанием своего SIDa. SID получаеться из другого, не менее специализированного VIEW - v$session. На специальные обьекты естественно необходимы специальные права доступа, которые мне незамедлительно и предоставили. Радостный, запустил новый запрос и стал ждать, подглядывая за ввереным спец-вью одним глазом. Вторым же, дабы не тратить время попусту, уставился в гугл на предмет детального обьяснения свеже-узнанных магических слов (см. "NOLOGGING" и "PARALLEL") в контексте индексов БД Oracle. Толковый дядька обьяснил, что первое, будучи произнесённым, отключит запись производимых действ в recoveri log (журнал такой, где храняться записи о содееном). Второе же позволит использовать много процессоров одновременно, если они конечно имеються в наличии, что чудесным образом сказываеться на рождаемости индексов.
Было дело, работал с сервером у которого было 24 процессора и считал что крут. Судя по выше обозначенному примеру, сервер там с 36-ю камешками. Как говориться, не возгордись... :)
Суть да дело, прошло 2 часа. Шаманский вью показывает, что перемалываеться уже 12тый кусок данных. Цифири в загадочных колонках SOFAR и TOTALWORK каждый раз разные, что всё это значит непонятно. Судя по всему будет продолжение!