Дядьки, а помочь слабо?

[alp 0]

А вопрос консистентности решен? Грубо бежать эта штука будет часов эдак 16. За это время призойдут изменения. Их тоже нужно будет нятянуть...

[Yevgen35 0]

А вопрос консистентности решен? Грубо бежать эта штука будет часов эдак 16. За это время призойдут изменения. Их тоже нужно будет нятянуть...

А еще можно налететь на "SNAPSHOT TOO OLD".

 

Ну что-ты к человеку пристаешь?

В MSSQL этого не надо, там все рулез и так изначально.

Ну подумаешь перечитает все сначала.....

Вишь как быстро шуршит, аж 1,5млн за час.

[AgentXXX 1]

Дядьки, всё консистентно,все дататипы в порядке, всё как надЫть, у мИне саще!

У кого будет какое другое саще, и прочие изменения мне до лампочки.

Отпуск подписан.Гы 10 раз.

 

ПыСы.А то что индексы на оракле не ребилдались с 06.2006 и статистики в перделе с такого же времени - меня тоже никак не касаеццО, у нас для этого спец-песец-ораклоид имееццО.

 

Их тоже нужно будет нятянуть...

Натянем.

 

аж 1,5млн за час.

Для двупроцессорного гроба 2005 года выпуска с памятью 2 гбт - вполне ничё так.

[Warm 0]

Если проблема в перекачке большого объема данных из Oracle в MSSQL, то можно попробовать так.

 

То что индексы не перестроены - это, конечно, грустно. Не знаю как в Oracle, но в MSSQL есть возможность медленной и нудной перестройки индексов без лока исходной таблицы (раз уж у вас там все непрерывно движется). Аналогичная проблема решалась в свое время с помощью DTS в MSSQL. Только млн. было 300 Пишется DTS пакет, перекачивающий из оракла в MSSQL данные по кускам (по датам, id и т.д.) размером 10000-1000000 (в зависимости от качества идексов), ограничители кусков передаются в виде параметров в DTS. И пишется цикл, который дергает этот DTS и логирует куда-нить о том, что выполнил (чтобы можно было прервать и начать с того же места). В результате данные перекачиваются маленькими порциями, локи на таблицах короткие и нет опасности начать все заново в случае, например, обрыва соединения. Не знаю, есть ли в Oracle аналог кластерного индекса, но если есть, то проблем с локами рабочей таблицы быть не должно. Короче, главное - правильно выбрать по какому критерию разбивать на части, а это можно сделать зная особенности вставляемых данных и принцип обновления. Ну и индексы желательно как-то иметь, иначе каждый выбор куска будет мучительным насилием над таблицей . На хороших индексах и неплохом оборудовании у меня на 250 млн ушла ночь.

[alp 0]

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

 

В оракле такая проблема отсутсвует как класс.

[Warm 0]

В оракле такая проблема отсутсвует как класс.

 

С полной блокировкой таблицы вы имеете в виду? В MSSQL она тоже решается разными хинтами (иногда правда оптимизатор на это подзабивает ) или кластерными индексами. Или с чем?

[alp 0]

Проблема блокировки записей при чтении.

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

[Yevgen35 0]

В MSSQL она тоже решается разными хинтами (иногда правда оптимизатор на это подзабивает ) или кластерными индексами. Или с чем?

Ну да, знаем мы как она решается.....

Либо "Dirty Read" либо висим на блокировках - выбор не большой.

Оба варианта хреновые, но других у МSSQL просто нет.

 

Постепенно Мicrosoft доделывает недостающие фитчи, пытаясь из блокировочника сделать версионник.

Но что-то пока у них с этим туго.

 

Кластерные индексы - в Oracle называются IOT(Index-Organized Table).

Кроме этого обычные B-Tree индексы с версии Oracle 8i можно перестраивать On-line.

 

ПыСы.А то что индексы на оракле не ребилдались с 06.2006 и статистики в перделе с такого же времени - меня тоже никак не касаеццО, у нас для этого спец-песец-ораклоид имееццО.

Если ты тянешь весь объем данных из одной таблицы, то индексы тебе не нужны совсем.

FULL TABLE SCAN - твой друг в этом случае.

 

Поэтому можешь попыться немного ускорить.

1. Сразу после запуска сессии

ALTER SESSION SET MULTIBLOCK_READ_COUNT=128; ( при размере блока 8к)

 

2. Хинт в запросе

 

SELECT /*+ FULL(IBE_SEGUIMIENTO) */

NUMERO_

......

FROM IBE_SEGUIMIENTO

[Warm 0]

Ну да, знаем мы как она решается.....

Либо "Dirty Read" либо висим на блокировках - выбор не большой.

Оба варианта хреновые, но других у МSSQL просто нет.

Постепенно Мicrosoft доделывает недостающие фитчи, пытаясь из блокировочника сделать версионник.

Но что-то пока у них с этим туго.

 

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

 

 

Если ты тянешь весь объем данных из одной таблицы, то индексы тебе не нужны совсем.

FULL TABLE SCAN - твой друг в этом случае.

 

Если все качать одним махом - да. Но на 25 млн - это немного рисковано, особенно если на разных серверах. Перекачается 24 млн. и сеть сглючит, в этом случае принимающая сторона (в виде MSSQL, если я не ошибаюсь) будет долго и нудно откатывать кучу незавершенных транзакций. Если все пройдет удачно, он будет не менее долго и нудно фиксить их. А если качать по частям, постоянный фуллскан будет далеко не супер.

[AgentXXX 1]

то индексы тебе не нужны совсем

Ага, я всегда знал, что на скорости доступа к данным это совсем не зависит.

Видать компухтеру просто не хватало ресурса заснепшотить хрень.Вот и усё.

 

в свое время с помощью DTS в MSSQL

Сейчас это у мелкомягких называеццО SSIS.Разработка усложнилась, цяцек навешали, машина в тормозе без 2 гига рамки.

Но, есть и масса положительных моментов.Особенно в плане параметризации.

Ну да ну их ...

Главная цель достигнута.

 

НА РАБОТУ АЖ ПОСЛЕ НОВОГО ГОДА!!!!!УРА!!!!!!!!

[Jin 0]

Ага, я всегда знал, что на скорости доступа к данным это совсем не зависит.

Видать компухтеру просто не хватало ресурса заснепшотить хрень.Вот и усё.

Сейчас это у мелкомягких называеццО SSIS.Разработка усложнилась, цяцек навешали, машина в тормозе без 2 гига рамки.

Дядько, что вы уперлись в эти два гига?

У меня в ноутбуке четыре.

Но это ничего не значит.

Программы надо уметь писать.

[jes 0]

НА РАБОТУ АЖ ПОСЛЕ НОВОГО ГОДА!!!!!УРА!!!!!!!!

Рано расслабился, мне до 23 числа твою хрень разобрать, пересчитать, залить дальше надо, так что ты или телефон закопай и сам закопайся или будь готов 24/7/365 быть на связи.

Удачно отдохнуть

[younghacker 7]

Дядько, что вы уперлись в эти два гига?

У меня в ноутбуке четыре.

Но это ничего не значит.

Программы надо уметь писать.

+1

Именно писать, а не собирать экскаватором. Скоро и ассемблерщиков можно будет пересчитать на пальцах одной руки.

[Yevgen35 0]

Ага, я всегда знал, что на скорости доступа к данным это совсем не зависит.

Надеюсь ты не серьезно это сказал иначе ты просто не понимаешь, как оно на самом деле работает.

 

Просто в зависимотсти от задачи используется разное средство ( оптимизатор выбирает соотв. PATH ) для доступа к данным или ты ему подсказываешь с помощью хинта, какой план исполнения запроса выбрать.

 

Если тебе нужно выбрать небольшой объем данных, то доступ по индексу самое то, а если ты собираешься читать весь объем данных то индек тебе уже не нужен.

А еще для индекса очень важна кроме объема данных его селективность.

Это как в библиотеке.

Если будешь выносить все книги, то нахрена смотреть в каталоге их месторасположение, а потом выносить.

 

 

Далее про Full Table Scan.

Если данные таблицы лежат правильно в экстентах (экстенты кратны 1М), то при упомянутых выше параметрах процесс осуществляющий сканирование таблицы, будет работать максимально эффективно ибо 1М это есть размер Max IO OS ( кол-во данных считываемых ядром ОС за 1 io request )

Так как известно, что ОС обычно редко читает по одному блоку данных,

а использует алгоритм READ AHEAD.

 

 

Про память.

Объем оператвной памяти как и объем кэша СУБД в этом случае не имеет значение совсем.

Потому, что в общем случае при операциях Full Table Scan Oracle cчитывая блоки в Кэш СУБД тут же с ними прощается. То есть в результате на одну таблицу, не зависимо от раземра таблицы он держит примерно 1М /8192 = 128 блоков. Дальше идет их вытеснение/замещение последующими операциями IO.

[AgentXXX 1]

мне до 23 числа твою хрень разобрать

Ничего разбирать не надо.

Усё будет там где тебе надо.Гы!

 

ты просто не понимаешь

Да потому как тебя послушать , так индексы вроде как изобрели просто для того чтобы занимать место.

Просто, для решения этой траблы мне в конечном итоге важен был индекс.А не просто выбор всех данных из таблицы.