Привет

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

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

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

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

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

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

Dmitry67 писал(а):

Big Cheese писал(а):

tengiz писал(а):

Dmitry67 писал(а):...то какой план выберет 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 данными во времени (или как то иначе)? Подозреваю что нет.

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

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

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

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

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

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

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

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

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

tengiz писал(а):

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

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?

zVlad писал(а):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?

To Tengiz.

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

zVlad писал(а):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. Но опять же, полученный результат - чисто для информации для нетерпеливых и нервных пользователей.

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

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

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

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

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

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

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

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

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