ODBC driver для SQL 2000

Big Cheese · Post by **Big Cheese** » 07 Oct 2003 06:44

tengiz wrote:
Dmitry67 wrote:...то какой план выберет SQL для выбора 998000 записей ? Правильно, full table scan. И напорется на блокировку

Ну-ну. А если всё-таки чуть-чуть подумать и сделать правильный индекс, как я уже писал, а не абы какой?

Я не специалист в MS SQL (как впрочем и в других DBMS :oops:

), но рискну высказаться: я так понимаю, что в данной ситуации единственный вариант, который будет предпочтительнее full table scan - это clustered index scan, причем SaleDate либо единственное, либо первое поле, по которому строится этот индекс. Так как по своей сути clustered index может быть только один на таблицу, в реальной ситуации, когда структура таблицы уже задана, этот вариант с большой вероятностью неприменим (хотя для данного абстрактного примера это требование вполне выполнимо). Буду рад выслушать комментарии специалистов.

Dmitry67 · Post by **Dmitry67** » 07 Oct 2003 08:01

Big Cheese wrote:
tengiz wrote:
Dmitry67 wrote:...то какой план выберет SQL для выбора 998000 записей ? Правильно, full table scan. И напорется на блокировку

Ну-ну. А если всё-таки чуть-чуть подумать и сделать правильный индекс, как я уже писал, а не абы какой?
Я не специалист в MS SQL (как впрочем и в других DBMS ), но рискну высказаться: я так понимаю, что в данной ситуации единственный вариант, который будет предпочтительнее full table scan - это clustered index scan, причем SaleDate либо единственное, либо первое поле, по которому строится этот индекс. Так как по своей сути clustered index может быть только один на таблицу, в реальной ситуации, когда структура таблицы уже задана, этот вариант с большой вероятностью неприменим (хотя для данного абстрактного примера это требование вполне выполнимо). Буду рад выслушать комментарии специалистов.

Если мы ишем по дате какие то документы по продажам то наверняка clustered index будет по другому полю - identity, guid или какой то иной уникальный идентификатор

tengiz · Post by **tengiz** » 07 Oct 2003 08:37

Давайте всё-таки чуть чуть подумаем. Во-первых, речь идёт об отчётах, а не ad-hoc запросах, во-вторых, никто никогда не ищет девятьсот тысяч полных документов - ну нашлись они - и что с ними делать? Просматривать? В подавляющем большинстве случаев речь идёт об агрегатах. Откуда, как минимум, следующие опции: 1) covering query для агрегатов; 2) indexed view с нужными агрегатами. Причём такие, чтобы запрос с диапазонным предикатом по дате приводил к index range scan. Хотя есть варианты, когда даже и это (range scan) не обязательно.

Теперь по поводу кластерных индексов. Выбор identity, GUID или другого уникального идентификатора в качестве кластерного ключа не является автоматически правильным - это просто почти гарантированно не является худшим выбором. Но не самый худший ещё не значит самый лучший, не правда ли? Поэтому если прогнозируется высокая вероятность клинчей между интенсивно запрашиваемыми отчётами и онлайновой активностью на обновление, и когда при этом отчёты от текущей активности чётко отделены датой, то кластерный индекс с датой в качестве ведущей колонки является одним из вариантов, которые нужно абсолютно иметь в виду при проектировании системы.

Dmitry67 · Post by **Dmitry67** » 07 Oct 2003 10:38

tengiz, ну что я Вам скажу...
Помните анекдот про потерявшихся на воздушном шаре ?
- Скажите, где мы ?
- Вы на воздушном шаре !
Абсолютно правильный и бесполезный ответ

То что Вы пишите правильно. Но скорее подходит для планирования написания новой аппликации. Какие indexed view ? Классная вещь но палка о двух концах - Вам же потом кое что отрежут за падение скорости OLTP
Ладо если еще кверь можно изменить. Тут плакались что PeopleSoft сама их генерит и хрен что поменять можно
В общем, welcome to the real world !

zVlad · Post by **zVlad** » 07 Oct 2003 12:05

tengiz wrote:........ Выбор identity, GUID или другого уникального идентификатора в качестве кластерного ключа не является автоматически правильным - это просто почти гарантированно не является худшим выбором. Но не самый худший ещё не значит самый лучший, не правда ли? ......

Нет не правда. В реальной жизни (абсолютно согласен с Dmitry67) не самый худший для каждого отдельного запроса - это и есть самый лучший для всей совокупности непредсказуемых заранее запросов.

zVlad · Post by **zVlad** » 07 Oct 2003 12:07

Dmitry67 wrote:tengiz, ну что я Вам скажу...
Помните анекдот про потерявшихся на воздушном шаре ?
- Скажите, где мы ?
- Вы на воздушном шаре !
Абсолютно правильный и бесполезный ответ

То что Вы пишите правильно. Но скорее подходит для планирования написания новой аппликации. Какие indexed view ? Классная вещь но палка о двух концах - Вам же потом кое что отрежут за падение скорости OLTP
Ладо если еще кверь можно изменить. Тут плакались что PeopleSoft сама их генерит и хрен что поменять можно
В общем, welcome to the real world !

Кстати Dmitry67 полный текст анекдота будет:

Ватсон и Холмс летят на воздушное шаре. Туман. Решили прижаться к земле и кого-нибудь спросить о местности. Спускаются . Видят человека. Спрашивают. Подумав тот отвечает - вы на воздушном шаре. Снова поднимаются. Холмс спрашивает Ватсона - ты мол понял кто это был. Нет. Это был системный программист (кстати можно и DBA). Почему? Ты видел он нас внимательно выслушал, подумал, и дал нам совершенно бесполезный, но правильный ответ. Гениально Холмс!

zVlad · Post by **zVlad** » 07 Oct 2003 12:18

Dmitry67 wrote:
Big Cheese wrote:
tengiz wrote:
Dmitry67 wrote:...то какой план выберет SQL для выбора 998000 записей ? Правильно, full table scan. И напорется на блокировку

Ну-ну. А если всё-таки чуть-чуть подумать и сделать правильный индекс, как я уже писал, а не абы какой?
Я не специалист в MS SQL (как впрочем и в других DBMS ), но рискну высказаться: я так понимаю, что в данной ситуации единственный вариант, который будет предпочтительнее full table scan - это clustered index scan, причем SaleDate либо единственное, либо первое поле, по которому строится этот индекс. Так как по своей сути clustered index может быть только один на таблицу, в реальной ситуации, когда структура таблицы уже задана, этот вариант с большой вероятностью неприменим (хотя для данного абстрактного примера это требование вполне выполнимо). Буду рад выслушать комментарии специалистов.

Если мы ишем по дате какие то документы по продажам то наверняка clustered index будет по другому полю - identity, guid или какой то иной уникальный идентификатор

Вы че парни, теорию никогда не читали? Уникальный кластерный индекс должен быть создан для ПЕРВИЧНОГО КЛЮЧА. Таблице в OLTP базе ДОЛЖНЫ быть нормализованны, а для репортинга ДОЛЖН быть создан WAREHOUSE, где храняться агрегированные данные. Или уже забыли?

Кстати давайте спросим Kon-a: а правда что Ваши репорты строятся по данный разнесенным с OLTP данными во времени (или как то иначе)? Подозреваю что нет.

Dmitry67 · Post by **Dmitry67** » 07 Oct 2003 13:31

zVlad wrote:1
Таблице в OLTP базе ДОЛЖНЫ быть нормализованны,

2
а для репортинга ДОЛЖН быть создан WAREHOUSE, где храняться агрегированные данные. Или уже забыли?

3
Кстати давайте спросим Kon-a: а правда что Ваши репорты строятся по данный разнесенным с OLTP данными во времени (или как то иначе)? Подозреваю что нет.

1 это в теории

2 если отчеты не online
3 У него PeopleSoft и отчеты писал не он

tengiz · Post by **tengiz** » 07 Oct 2003 16:16

Dmitry67 wrote:То что Вы пишите правильно. Но скорее подходит для планирования написания новой аппликации. Какие indexed view ? Классная вещь но палка о двух концах - Вам же потом кое что отрежут за падение скорости OLTP. Ладо если еще кверь можно изменить. Тут плакались что PeopleSoft сама их генерит и хрен что поменять можно. В общем, welcome to the real world !

Новая своя аппликация или старая чужая - никто не мешает создать полезный индекс. И за что, по-Вашему, скорее отрежут в the reald world - за небольшое падение производительности или за ошибки в отчётах из-за грязного чтения? Если возможность гонять эти отчёты постоянно настолько важна, то новый индекс - отнюдь не самая большая плата за необходимую функциональность. Да и без правильного индекса производительность всё равно может быть хуже из-за блокирования, так что это ещё большой вопрос, что в итоге будет быстрее.

tengiz · Post by **tengiz** » 07 Oct 2003 16:29

zVlad wrote:Вы че парни, теорию никогда не читали? Уникальный кластерный индекс должен быть создан для ПЕРВИЧНОГО КЛЮЧА.

1) В теории нет понятия кластерного индекса. 2) в реальной жизни кластерный индекс - очень важный ресурс, потому, что таковой на таблицу только один. Поэтому какой именно индекс сделать кластерным должно быть результатом тщательного планирования и продумывания.

И, наконец, по поводу адекдота. Классическое продолжение - после того, как те на воздушном шаре высказались о своей блестящей догадке, программист (DBA или математик, как было в оригинале) заметил, что задавший вопрос, скорее всего, менеджер. Почему? Да потому, что очень ловко перевёл стрелки, получивши правильный, но не устраивающий его ответ.

zVlad · Post by **zVlad** » 07 Oct 2003 16:38

tengiz wrote:
zVlad wrote:Вы че парни, теорию никогда не читали? Уникальный кластерный индекс должен быть создан для ПЕРВИЧНОГО КЛЮЧА.

1) В теории нет понятия кластерного индекса. 2) в реальной жизни кластерный индекс - очень важный ресурс, потому, что таковой на таблицу только один. Поэтому какой именно индекс сделать кластерным должно быть результатом тщательного планирования и продумывания.

И, наконец, по поводу адекдота. Классическое продолжение - после того, как те на воздушном шаре высказались о своей блестящей догадке, программист (DBA или математик, как было в оригинале) заметил, что задавший вопрос, скорее всего, менеджер. Почему? Да потому, что очень ловко перевёл стрелки, получивши правильный, но не устраивающий его ответ.

To the my best memorizing, in theory there is no index at all. Regardless clustered or not. Correct?
Question left is what “dirty read” was introduced and made for?

tengiz · Post by **tengiz** » 07 Oct 2003 16:50

zVlad wrote:To the my best memorizing, in theory there is no index at all. Regardless clustered or not. Correct?

Correct.

Question left is what “dirty read” was introduced and made for?

Could you please remind me what the actual question was?

zVlad · Post by **zVlad** » 07 Oct 2003 18:40

To Tengiz.

Original question was how to run reports without contention with OLTP processing.

tengiz · Post by **tengiz** » 07 Oct 2003 21:32

zVlad wrote:Original question was how to run reports without contention with OLTP processing.

Да нет, я спрашивал в чём Ваш был вопрос? А что касается исходного вопроса, начавшего дискуссию, то своё мнение я уже изложил. Могу только повторить, что грязное чтение в подавляющем большинстве непатологических случаев - это самый последний и самый худший вариант, который я бы рассматривал. Необходимость в нём возникает, как правило, только в крайне неудачно или безграмотно спроектированных приложениях БД. А также при миграции с того же ORACLE на DB2 или MS SQL, если приложение на ORACLE писалось чистым ораклистом, не имеющем понятия о том, как устроены блокировочные сервера.

Приемлимый вариант использования грязных чтений - когда администратору нужно быстро продиагностировать какую-либо проблему и когда результаты таких запросов далее не идут ни в какую отчётность, на их основе не принимаются никакие бизнес-решения, и пр. А также, например, когда приложение имеет, скажем, progress indicator, который выполняет что-то типа select count (*) from sometable where processed = true в течение времени пока какая-нибудь большая длинная транзакция трогает строки в sometable и по мере их модификации меняет колонку processed. Но опять же, полученный результат - чисто для информации для нетерпеливых и нервных пользователей.

zVlad · Post by **zVlad** » 08 Oct 2003 12:31

Tengiz, я не задавал каких-либо вопросов иных чем тема топика. Собствено, все уже отвечено. No questions.

tchicago · Post by **tchicago** » 09 Oct 2003 17:33

tengiz wrote:приложение на ORACLE писалось чистым ораклистом, не имеющем понятия о том, как устроены блокировочные сервера.

Тенгиз, а где можно об этом почитать?

Merle · Post by **Merle** » 09 Oct 2003 20:10

tengiz wrote:Приемлимый вариант использования грязных чтений - когда администратору нужно быстро продиагностировать какую-либо проблему и когда результаты таких запросов далее не идут ни в какую отчётность, на их основе не принимаются никакие бизнес-решения, и пр. А также, например, когда приложение имеет, скажем, progress indicator, который выполняет что-то типа select count (*) from sometable where processed = true в течение времени пока какая-нибудь большая длинная транзакция трогает строки в sometable и по мере их модификации меняет колонку processed. Но опять же, полученный результат - чисто для информации для нетерпеливых и нервных пользователей.

А вот кстати, Tengiz, если позволите немного провокационный вопрос.
А в tpc-c тесте MSSQL'я использовался ли где-нибудь READ UNCOMMITTED?

tengiz · Post by **tengiz** » 09 Oct 2003 20:44

Merle wrote:А в tpc-c тесте MSSQL'я использовался ли где-нибудь READ UNCOMMITTED?

Nope. В противном случае результаты таких прогонов были бы забракованы. Тест изоляции транзакций - важная составная часть TPC-C.

tengiz · Post by **tengiz** » 09 Oct 2003 20:45

tchicago wrote:Тенгиз, а где можно об этом почитать?

Я думаю, что во всяких migration kits много об этом должно быть информации. Если я, конечно, правильно понимаю, что Вас интересует.

tchicago · Post by **tchicago** » 09 Oct 2003 23:06

tengiz wrote:Я думаю, что во всяких migration kits много об этом должно быть информации. Если я, конечно, правильно понимаю, что Вас интересует.

Да, есть на MSDN документ, но там по блокировкам буквально несколько абзацев, и то все в том духе, что в MS SQL динамические блокировки, и разработчику не нужно об этом думать, только разрабатывать себе в свое удовольствие, ну разве что транзакции покороче делать.

Я вот заказал какой-то 4-дисковый учебный кит по миграции, может там чего повнятней напишут.

tengiz · Post by **tengiz** » 10 Oct 2003 00:13

tchicago, вроде пару дней назад zVlad выкладывал ссылку на документ о миграции с ORACLE на DB2 - это тоже может быть полезно. Да и здесь, на Привете уже было несколько длинных дискуссий на смежные темы - поищите в архивах, тоже может оказаться интересным.