MS SQL - row size limit

tengiz · Post by **tengiz** » 25 Mar 2004 08:22

KVA wrote:Да я и не знаю, я просто спрашиваю. Но с другой стороны никто вроде не заявлял громко что Oracle на Windows уступает MS SQL в производительности из-за размера страниц. А раз не уступает, то и проблема не такая уж серьезная, а раз так, то почему есть ограничение в MS SQL.

Ограничение на размер строки размером страницы даёт возможность использовать очень эффективную оптимизацию при сканировании диапазонов в индексе. В этом одно из заметных отличий MS SQL от Oracle, где такая оптимизация невозможна и поэтому там где MS SQL для выдачи сортированного набора просто сканирует индекс, Oracle делает чтение страниц в их реальном физическое порядке, а затем делает сортировку.

YellowMan · Post by **YellowMan** » 25 Mar 2004 11:27

Tengiz, Вы так сказали будто бы этих заметных отличий мало и ширина таблицы одна из самых важных

KVA wrote:В общем я не пытаюсь обидеть фанатов MS SQL. Просто кое-что непонятно.

Да мы не фанаты - мы с ним работаем. Еще не хватало серверу молиться или у оптимизатора автограф просить

KVA · Post by **KVA** » 25 Mar 2004 13:47

Спасибо, Tengiz

Да мы не фанаты - мы с ним работаем. Еще не хватало серверу молиться или у оптимизатора автограф просить

Да кто его знает. Тут столько тем было. Чуть тронешь чью-нибудь любимую OS, compiler, DB, etc народ сразу рубаху на груди рвет и в драку лезет.

vc · Post by vc » 25 Mar 2004 15:01

Hello Kemosabe. How's that tundra beastie shaping up ?

tengiz wrote:
KVA wrote:Да я и не знаю, я просто спрашиваю. Но с другой стороны никто вроде не заявлял громко что Oracle на Windows уступает MS SQL в производительности из-за размера страниц. А раз не уступает, то и проблема не такая уж серьезная, а раз так, то почему есть ограничение в MS SQL.

Ограничение на размер строки размером страницы даёт возможность использовать очень эффективную оптимизацию при сканировании диапазонов в индексе. В этом одно из заметных отличий MS SQL от Oracle, где такая оптимизация невозможна и поэтому там где MS SQL для выдачи сортированного набора просто сканирует индекс, Oracle делает чтение страниц в их реальном физическое порядке, а затем делает сортировку.

Some Microsoft resident Oracle guru must have misled you.

Consider this:

Code: Select all

SQL> create table t1 as select * from all_objects;

SQL> describe t1;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 OWNER                                     NOT NULL VARCHAR2(30)
 OBJECT_NAME                               NOT NULL VARCHAR2(30)
 SUBOBJECT_NAME                                     VARCHAR2(30)
 OBJECT_ID                                 NOT NULL NUMBER
 DATA_OBJECT_ID                                     NUMBER
 OBJECT_TYPE                                        VARCHAR2(18)
 CREATED                                   NOT NULL DATE
 LAST_DDL_TIME                             NOT NULL DATE
 TIMESTAMP                                          VARCHAR2(19)
 STATUS                                             VARCHAR2(7)
 TEMPORARY                                          VARCHAR2(1)
 GENERATED                                          VARCHAR2(1)
 SECONDARY                                          VARCHAR2(1)


... here we sort:

SQL> select * from t1 where object_name between 'A' and 'C' order by object_name;
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   SORT (ORDER BY)
   2    1     TABLE ACCESS (FULL) OF 'T1'

SQL> create index t1_idx on t1(object_name);

Index created.


... and here we don't:

SQL> select * from t1 where object_name between 'A' and 'C' order by object_name;
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'T1'
   2    1     INDEX (RANGE SCAN) OF 'T1_IDX' (NON-UNIQUE)

Best regards.

tengiz · Post by **tengiz** » 25 Mar 2004 16:12

vc wrote:Some Microsoft resident Oracle guru must have misled you.

И имя этого гуру - vc. Только он не местный

.

Напоминаю, что некоторое время назад мы подробнейшим образом разбирали, что как только предполагаемый объём сканированных данных превышает некоторый порог, Oracle предпочитает физическое чтение с последующей сортировкой. Причина - при сканировании диапазона индекса Oracle не может использовать readahead потому что для чтения цепочки страниц индекса он должен читать страницы по одной. SQL Server же умеет использовать внутренние страницы индекса для "глубокого" readahead.

Так как не иметь кластерного индекса для таблицы MS SQL - это исключение, то возможноть быстного чтения btree принципиальна с точки зрения обеспечения хорошей производительности длинных чтений.

Ваш эксперимент не имеет большого смысла без статистики физического IO в случае наличия или отсуствия индекса - если таблица содержит дюжину страниц, то это абсолютно ни о чём не говорит. Тем более, что в той дискусси Вы показывали примеры, показывающие совершенно противоположное поведение Oracle, когда если я правильно помню, при наличии индекса и агрерациии по ведущей колонке индекса, Oracle делал физическое чтение, сортировку а затем аргерацию.

tengiz · Post by **tengiz** » 25 Mar 2004 16:20

YellowMan wrote:Tengiz, Вы так сказали будто бы этих заметных отличий мало и ширина таблицы одна из самых важных

Дело не в ширине страницы - дело в том, чтобы всю строку уложить в страницу, чтобы для чтения целой строки не приходилось прыгать по цепочке страниц, составляющих одну строку - простые реализации таких цепочек не позволяют делать предварительную выборку. Вплоть до SQL Server 2000 ограничение на размер строки не особенно тревожило подавляющее большинство пользователей. Как только начнёт всерьёз тревожить - вот тогда посмотрим.

vc · Post by vc » 25 Mar 2004 17:21

tengiz wrote:
vc wrote:Some Microsoft resident Oracle guru must have misled you.

И имя этого гуру - vc. Только он не местный .

Напоминаю, что некоторое время назад мы подробнейшим образом разбирали, что как только предполагаемый объём сканированных данных превышает некоторый порог, Oracle предпочитает физическое чтение с последующей сортировкой. Причина - при сканировании диапазона индекса Oracle не может использовать readahead потому что для чтения цепочки страниц индекса он должен читать страницы по одной. SQL Server же умеет использовать внутренние страницы индекса для "глубокого" readahead.

Well, yes, if the optimizer decides (based on statistics) that reading the table directly and then sorting is cheaper than index access (which is undoubtedly more heavy-weight than Microsoft's), then the choice is obvious, no argument about that.

tengiz wrote:Ваш эксперимент не имеет большого смысла без статистики физического IO в случае наличия или отсуствия индекса - если таблица содержит дюжину страниц, то это абсолютно ни о чём не говорит. Тем более, что в той дискусси Вы показывали примеры, показывающие совершенно противоположное поведение Oracle, когда если я правильно помню, при наличии индекса и агрерациии по ведущей колонке индекса, Oracle делал физическое чтение, сортировку а затем аргерацию.

Again, it's up to the optimizer what acces path to choose. I merely wanted to show that, in Oracle, such access path does exist and will be used if it's more beneficial than the alternative, all other things being equal. E.g., if a fraction of a multi-million row table is 'ordered by', then the index path will be chosen for the same reason as for my small table.

VC

tengiz · Post by **tengiz** » 25 Mar 2004 18:54

vc,

What you say is sure related yet hardly relevant - разумеется оптимизатор Oracle в состоянии сделать план, который будет использовать индекс для сканирования относительно короткого диапазона ключей . Но я говорю о дргугом. Каждый логический оператор помещаемый в план оптимизатором имеет одну или более одной физическую реализацию и решение о том, какую конкретно использовать иногда делается уже на этапе выполнения (а не оптимизации). Физическая реализация оператора сканирования индекса в Oracle не имеет опции оптимизации предварительной выборки страниц индекса, тогда как SQL Server имеет - чему очень способствует ограничение на максимальный размер строки. Это всё, что я имел в виду.

vc · Post by vc » 25 Mar 2004 20:51

tengiz wrote:vc,

Физическая реализация оператора сканирования индекса в Oracle не имеет опции оптимизации предварительной выборки страниц индекса, тогда как SQL Server имеет - чему очень способствует ограничение на максимальный размер строки. .

Here, we are in complete agreement...

Dmitry67 · Post by **Dmitry67** » 26 Mar 2004 09:22

Тем не менее это ограничение
Можно было бы просто не делать такой классной оптимизации для таблиц которые больше 8K
Но они бы работали как в Оракле

YellowMan · Post by **YellowMan** » 26 Mar 2004 11:38

Как только начнёт всерьёз тревожить - вот тогда посмотрим.

За 10 лет в бизнесе я только 2 раза видел таблицу ширина которой была больше 8К - и оба раза это было неграмотное проектирование. К своему стыду один из разов был мой :oops:

- но зато очень давно

Правильно ли я понимаю что если бы была возможность менять размер страницы - в идеале для каждой таблицы - проблема бы ушла с сытыми волками и целыми овцами ? К примеру сделать страницу кратной размеру strip в RAID array. Или слишком много переделывать ? Или я не все понимаю ?

И раз уж пошла беседа - еще один злосный оффтопик : с каким уровнем блокировки выполняется rollback ? Иными словами могут ли 2 конкурентных rollback попасть в deadlock и если могут, то что сделает сервер ?

zVlad · Post by **zVlad** » 26 Mar 2004 13:18

DB2 предлагает на выбор страницы размером 4, 8, 16, 32К на выбор. Соответственно длина строки ограничивается по разному. Страница выбирается на уровне табличного пространства, т.е. в принципе каждая отдельная таблица может иметь свой размер (из доступных) страницы.
Кроме того архитектура дисков мэйнфрэйм позволяет осуществлять чтение/запись множества страниц за одну операцию ввода/вывода.
При этом DB2 осуществляет (подобно другим базам) чтение с опережением в порядке кластерирующего индекса, или по списку (list prefetch) если таковой индекс не используется.

tengiz · Post by **tengiz** » 27 Mar 2004 03:18

YellowMan wrote:Правильно ли я понимаю что если бы была возможность менять размер страницы - в идеале для каждой таблицы - проблема бы ушла с сытыми волками и целыми овцами ? К примеру сделать страницу кратной размеру strip в RAID array. Или слишком много переделывать ? Или я не все понимаю ?

По теперешним временам если что-то всерьёз переделывать, то сразу на страницы переменного размера, а не просто дать возможность выбирать из нескольких фиксированных. И это заметно усложнит код, которые занимается выделением места на дисках, а также и buffer manager. Но оно того будет стоить, с моей точки зрения. Да и потом, в Yukon исходной проблемы уже нет. Размер переменной части строки там уже не ограничен (однако суммарный размер фиксированных данных по-прежнему ограничен размером страницы.) Но, как нетрудно догадаться, за это придётся платить меньшей эффективностью индексных сканов при наличии "широких" строк.

И раз уж пошла беседа - еще один злосный оффтопик : с каким уровнем блокировки выполняется rollback ? Иными словами могут ли 2 конкурентных rollback попасть в deadlock и если могут, то что сделает сервер ?

Не могут. Единственное икслючение - если это баг. Но никаких известных ошибках в этом коде приводящих к deadlock я не знаю.

alex_127 · Post by **alex_127** » 27 Mar 2004 11:39

tengiz wrote:
YellowMan wrote:
И раз уж пошла беседа - еще один злосный оффтопик : с каким уровнем блокировки выполняется rollback ? Иными словами могут ли 2 конкурентных rollback попасть в deadlock и если могут, то что сделает сервер ?

Не могут. Единственное икслючение - если это баг. Но никаких известных ошибках в этом коде приводящих к deadlock я не знаю.

Process in rollback can't be killed by deadlock detection. If all processes involved in deadlock are unkillable you have an unresolved deadlock.
I'm aware of only one bug which was fixed as QFE for SQL2000 when we got into this state. Please PM if you need additional info/have a repro.

Dmitry67 · Post by **Dmitry67** » 27 Mar 2004 11:53

А при каких случаях для rollback вообще надо кого то ждать кроме диска ?