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

[Warm 0]

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

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

 

Вы в данный момент по-моему говорите о разных вещах. Yevgen35 говорит о том, что если бы вы просто выгружали все данные без разбора из таблицы (грубо говоря, select * from <Table>), то вам индекс был бы не нужен, то есть индексы могли быть на вашей таблице, они могли быть не перестроенные уже лет 100 и это бы не отразилось на скорости выборки данных, так как оптимизатор все равно использовал бы full table scan. А поскольку у вас в запросе, видимо, был where по индексированным полям, вам индексы были принципиальны. Но кто ж знал, был он или нет

 

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

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

 

Когда проблема решалась, это был действительно еще DTS. Сила привычки не позволяет мне называть это сейчас неблагозвучным словом "SSIS". Не могу сказать, что их разработка сильно усложнилась, скорее, это одна из тех областей, в которой MS стремится к своей мечте - программированию с помощью мыши .

[Yevgen35 0]

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

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

Нет конечно, но только ими тоже надо уметь пользоваться.

Ты план исполнения своего запроса смотрел, или тебе просто кажется, что твой запрос должен был использоваться индекс?

 

1,5 млн в час сосёт.

Есть такое простое универсальное правило.

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

Оно гласит:

"Если из таблицы в результате запроса выбирается 20% данных, то использованию индекса скорей всего будет неэффективным "

 

25млн *0.2 = 5млн.

 

Сколько у тебя записей выбирается в результате запроса?

[AgentXXX 1]

Сегодня ночью пробежала выборка oт 6 до 50 записей, но 250 000 раз.

[Yevgen35 0]

Сегодня ночью пробежала выборка oт 6 до 50 записей, но 250 000 раз.

6x 250 000 = 1,5 млн

50 x 250 000 = 12,5 млн

[AgentXXX 1]

Не 12,5, только 7,5 получилось, хистори юзания за год.За 3 предидущих будет потом.Если будет.

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

Из 24 таблиц с оракла на сиквел.(SSIS)

[Jin 0]

не забудь всем пиво проставить

[AgentXXX 1]

Типа за моральную поддержку?

[Jin 0]

тестовая миграция данных за последний год пробежала?

[AgentXXX 1]

Ky

[serj_nv 2396]

Да-да админам програмеров не понять

[Yevgen35 0]

Да-да админам програмеров не понять

Смотря какие админы и смотря какие программеры.

 

Не 12,5, только 7,5 получилось, хистори юзания за год.

7,5 млн > 5млн

[Warm 0]

7,5 млн > 5млн

 

Так это ж суммарно, а каждый из 250 000 запросов выбирает маленький процент общего числа данных, что <20% и не противоречит вашему правилу об эффективном использования индекса

 

Да-да админам програмеров не понять

 

Понимание здесь не нужно, достаточно хорошего интерфейса взаимодействия

[Yevgen35 0]

Так это ж суммарно, а каждый из 250 000 запросов выбирает маленький процент общего числа данных, что <20% и не противоречит вашему правилу об эффективном использования индекса

Не ну если так, тогда я просто иду нервно курить.

Это типичные мысли программиста для которого СУБД - "черный ящик"

 

При при индексном поиске осуществляестя случайное одноблочное чтение ( читай дисковая подсистем чаще делает seek ), а после чего уже осуществляется чтение по ROWID из таблицы.

в то время как при FTS ( Full Table Scan) выполняется многоблочное последовательное чтение.

 

Объяснять думаю не требуется, что при последовательном чтении быстродействие дисковой подсистемы максимальное, с учетом выше-изложенного?

[Warm 0]

Не ну если так, тогда я просто иду нервно курить.

Это типичные мысли программиста для которого СУБД - "черный ящик"

 

При при индексном поиске осуществляестя случайное одноблочное чтение ( читай дисковая подсистем чаще делает seek ), а после чего уже осуществляется чтение по ROWID из таблицы.

в то время как при FTS ( Full Table Scan) выполняется многоблочное последовательное чтение.

 

Объяснять думаю не требуется, что при последовательном чтении быстродействие дисковой подсистемы максимальное, с учетом выше-изложенного?

 

Теперь нервно курить иду я

 

7,5 млн строк за один запрос из таблицы в 25 млн - вопроса нет. А выбрать из таблицы с 25 млн записей 50 строк тоже быстрее полным сканированием таблицы?

[Yevgen35 0]

7,5 млн строк за один запрос из таблицы в 25 млн - вопроса нет. А выбрать из таблицы с 25 млн записей 50 строк тоже быстрее полным сканированием таблицы?

Нет конечно.

В этом случае естественно индексный поиск рулит ибо читается несколько блоков индекса, а за ним прямой доступ к блокам в таблице.

 

Но если это делаеть 250 тыс раз (задачка то не OLTP), тогда это становится неэффективным с точки зрения IO

и как следствие времени выполнения.