|
|
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!andsm Проблемы с конкурентным доступом к последнему блоку данных действительно были, но они решены без всякого reverse index. такое проканает только если конкуренция только за блоки примарного ключа, если есть еще хотя бы один горячий индекс фокус не пройдет. и вообще тогда уж имхо проще самому примари кей было бы генерить не последовательно, хотя за неимением сиквенсов может оно и верно .... Эту проблему в большинстве случаев можно решить введя партиционирование горячего индекса. Yo.! andsm В этом случае можно запретить эскалации вообще, запретить эскалации ну сервер захлебнется в юлозании по огромному списку локов, мсдн об этом не раз предупреждает .... Можно запретить эскалации только на определенных таблицах (там где они вредны), и разрешить на остальных. В этом случае количество блокировок будет нормальным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2010, 14:01 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!sdvsamara Важно что эта фича именно для RAC и в другом случае не нужна. А так как MS SQL, насколько я знаю, таку конфигурацию не поддерживает, то ему этот индекс и не нужен. А вот если поддерживает, то это ошибка не иметь такой индекс. не понял, вы пытаетесь меня убедить, что мсскл единственная субд где мистическим образом конкуренции не происходит ? дык, не получится, да и andsm собственно разъяснил как в мсскл предлагается выкручиваться без реверс индекса. согласен, при условии, что драка происходит только за примари кей то проканает ... Можно я попробую повернуть беседу в конструктивное русло ( касательно сравнения конкурентного доступа к блокам). Пришел с новыми тезисами( мыслями). Зачем в СУБД вообще нужен индекс ? Правильно для ускорения поиска . И чем больше всевозможных критериев для поиска покрывает индекс, тем выше его юзабилити. Что мы имеем в 2-х выше перечисленных подходах. 1 . Подход Oracle, имеем некоторые проблемы со сканированием по диапазону индекса. ( проблемы с функциональностью индекса , что есть факт) 2. Подход MS не полностью решает проблемы конкуренции за изменение, зато его индекс более функционален с точки зрения его изначального предназначения. Что в конечном итоге окажет больший вес в конечной оценке производительности всей системы - тяжело сказать. Но допускать однобокое сравнение я нехочу. Прошу понять меня правильно , я пытаюсь быть не предвзятым в сравнении. зы show must go on :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2010, 14:25 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
andsm Эту проблему в большинстве случаев можно решить введя партиционирование горячего индекса. а разве можно навешивать индекс отпартиционированный по другому полю чем таблица ? andsmМожно запретить эскалации только на определенных таблицах (там где они вредны), и разрешить на остальных. В этом случае количество блокировок будет нормальным. угу, в больших ERP на мсскл так и предлагают выкручиваться, на ощупь искать баланс между конкурентным доступом и кол-вом блокировок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2010, 14:30 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
interesting2. Подход MS не полностью решает проблемы конкуренции за изменение, зато его индекс более функционален с точки зрения его изначального предназначения. Вы уверены? Далеко не факт, что сервер поддерживает range scan при таком партиционировании. interestingЧто в конечном итоге окажет больший вес в конечной оценке производительности всей системы - тяжело сказать. Но допускать однобокое сравнение я нехочу. Думаю, в любом случае, для оценки окажет большое значение доля range scan-ов по первичному ключу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2010, 14:31 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!andsm Эту проблему в большинстве случаев можно решить введя партиционирование горячего индекса. а разве можно навешивать индекс отпартиционированный по другому полю чем таблица ? Можно, если он не уникальный. Правильнее даже сказать так, что в уникальный индекс должно входить условие партиционирования таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2010, 14:40 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
softwarerinteresting2. Подход MS не полностью решает проблемы конкуренции за изменение, зато его индекс более функционален с точки зрения его изначального предназначения. Вы уверены? Далеко не факт, что сервер поддерживает range scan при таком партиционировании. Не уверен , я предложил тезисы требующие доказательств или опровержений, а не утверждения. Давайте будем считать эти тезисы моим ИМХО. softwarer interestingЧто в конечном итоге окажет больший вес в конечной оценке производительности всей системы - тяжело сказать. Но допускать однобокое сравнение я нехочу. Думаю, в любом случае, для оценки окажет большое значение доля range scan-ов по первичному ключу :) Полностью согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2010, 14:45 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
pkarklin wrote: > Trace Flags 1211 и 1224 Рад, что в MS таки сделали тонкую настройку эскалации. ( SET ( LOCK_ESCALATION = { AUTO | TABLE | DISABLE } ) ) Всё-таки не конченый продукт. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 10:43 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
interesting Можно, если он не уникальный. а что там за ограничения по типу данных ? если таблица разбита по примарному ключу, варчар индекс по другому правилу можно отпартиционировать? interestingя предложил тезисы требующие доказательств или опровержений, а не утверждения. ну и на кого же мы возложим бремя доказательств ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 14:19 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!угу, в больших ERP на мсскл так и предлагают выкручиваться, на ощупь искать баланс между конкурентным доступом и кол-вом блокировок. Ну, не совсем так, я бы даже сказал - совсем не так. Lock Partitioning ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 14:48 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!interesting Можно, если он не уникальный. а что там за ограничения по типу данных ? если таблица разбита по примарному ключу, варчар индекс по другому правилу можно отпартиционировать? Нет никаких ограничений по типам данных, есть ограничение со списком полей: ORA-14039 If the user, indeed, desired to create an index whose partitioning columns do not form a subset of its key columns, it must be created as non-UNIQUE; otherwise, correct the list of key and/or partitioning columns to ensure that the index' partitioning columns form a subset of its key columns Я думаю глубже эту тему вы сами нагуглить сможете. У Кайта ( на асктоме) вроде тоже обсуждалась эта тема. Yo.! interesting я предложил тезисы требующие доказательств или опровержений, а не утверждения. ну и на кого же мы возложим бремя доказательств ? Почему бремя ? Мне кажется тема интересна с точки зрения обещего професионального развития. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 15:08 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
pkarklin Ну, не совсем так, я бы даже сказал - совсем не так. Lock Partitioning вот спасибо ! а я бы сказал, что отличная иллюстрация на на какие ухищрения приходится идти ммскл когда юлозание по оргромным спискам локов переходит границу в 16 cpu. как я понимаю система с менее чем 16 cpu и отключенной эскалации вообще обречена. еще спасибо за ссылку, собственно она и объясняет почему дба вынужден искать баланс с конкурентным доступом, а не тупо отключить эскалацию на всю базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 15:10 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
interesting Нет никаких ограничений по типам данных, есть ограничение со списком полей: ну в оракле то я и не сомневался, а вот что означает эта фраза об мсскл: http://msdn.microsoft.com/en-us/library/ms187526.aspxAn index does not have to participate in the same named partition function to be aligned with its base table. However, the partition function of the index and the base table must be essentially the same, in that 1) the arguments of the partition functions have the same data type, 2) they define the same number of partitions, and 3) they define the same boundary values for partitions. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 15:16 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!interesting Нет никаких ограничений по типам данных, есть ограничение со списком полей: ну в оракле то я и не сомневался, а вот что означает эта фраза об мсскл: Я вроде уже говорил , что не силен мсскл, За пару минут беглого просмотра приведенной вами ссылки напрашиваетмся вывод , что Вы либо не внимательно читали ссылку, либо пытаетесь выдернуть фрузу из контекста автор Aligning an index with a partitioned table is particularly important if you anticipate that it will expand by taking on additional partitions, or that it will be involved in frequent partition switches. For more information, see Designing Partitions to Manage Subsets of Data. When a table and its indexes are in alignment , SQL Server can switch partitions quickly and efficiently while maintaining the partition structure of both the table and its indexes Дальше то что вы процетировали ( типа ограничения , чем приходится платить за alignment indexes) http://msdn.microsoft.com/en-us/library/ms187526.aspxAn index does not have to participate in the same named partition function to be aligned with its base table. However, the partition function of the index and the base table must be essentially the same, in that 1) the arguments of the partition functions have the same data type, 2) they define the same number of partitions, and 3) they define the same boundary values for partitions. а еще дальше автор Generally, the Database Engine Tuning Advisor can be used to recommend indexes for performance, and this can be a mix of aligned and nonaligned indexes . For more information, see Database Engine Tuning Advisor Overview. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 15:49 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
interesting Я вроде уже говорил , что не силен мсскл, какой-то странный у нас получается разговор, вы в мсскл не сильны но при этом пытаетесь мне доказать, что там есть там есть то там есть се, совершенно не представляя, что там на самом деле есть, а чего нет. interestingЗа пару минут беглого просмотра приведенной вами ссылки а если присмотреться ? лично я не вижу, чтобы что-либо указывало что предупреждение относится лишь к alignment indexes. мало того http://msdn.microsoft.com/en-us/library/ms187526.aspx An index does not have to participate in the same named partition function to be aligned ... However на сколько мне хватает английского, я вижу прямое указание, что речь идет об индексе который не обязан быть aligned. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 16:31 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.! Ну, как обычно, в своем репертуаре. авторна какие ухищрения приходится идти ммскл когда юлозание по оргромным спискам локов переходит границу в 16 cpu. А вот в статье, как раз с точностью до наоборот. если в системе более 16 ЦПУ, то есть дополнительная фича, снижающая "юлозание по оргромным спискам локов". Только нет никакой коррелляции локи-цпу. Просто предполагается, что в системах с менее 16 цпу (не по кол-ву цпу, а по нагрузке, которая такая система должна держать) не так актуальна проблема "юлозание по оргромным спискам локов". авторкак я понимаю система с менее чем 16 cpu и отключенной эскалации вообще обречена. Совсем не правильно понимаете, ибо, как и в случае с "проблемами с tempdb" при включенной версионности, Вы выносите чисто имперические суждения, не подтвержденный практикой. У меня, к счастью, другой опыт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 17:42 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
pkarklinесли в системе более 16 ЦПУ, то есть дополнительная фича, снижающая "юлозание по оргромным спискам локов". Там вообще ни слова про "списки локов" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 17:45 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
pkarklin А вот в статье, как раз с точностью до наоборот. мы говорим об одной и той же статье ? собственно что за проблему решает мсскл партиционированием локов: msdnFor large computer systems, locks on frequently referenced objects can become a performance bottleneck as acquiring and releasing locks place contention on internal locking resources. оно становиться ботлнеком уже без отключения эскалации, что получится если еще и отключить эскалацию, что гарантированно увеличит кол-во локов на пару порядков, еще больше усугубляя проблему, которую мсскл пытается решить партиционированнием списка локов ? к стате почему взято какое-то магическое число 16 вообще не понятно. система менее чем 16 процев (которые ядра скорее всего) с отключенной эскалацией практически гарантированно будет иметь гораздо большую структуру локов, чем 16 процес с эскалациями. ЗЫ. намекаете, что ноты посвященные проблемам ио в темпдб не достаточный аргумент ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 18:53 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!interesting Я вроде уже говорил , что не силен мсскл, какой-то странный у нас получается разговор, вы в мсскл не сильны но при этом пытаетесь мне доказать, что там есть там есть то там есть се, совершенно не представляя, что там на самом деле есть, а чего нет. Я нигде Вам ничего не доказывал про MSSQL . Ни в вопросе ни в ответе MSSQL не звучало, пока Вы не процитировали MSDN под моей цитатой. Я попытался ответить , и сам паралельно подучился :) Yo.! interestingЗа пару минут беглого просмотра приведенной вами ссылки а если присмотреться ? лично я не вижу, чтобы что-либо указывало что предупреждение относится лишь к alignment indexes. мало того http://msdn.microsoft.com/en-us/library/ms187526.aspx An index does not have to participate in the same named partition function to be aligned ... However на сколько мне хватает английского, я вижу прямое указание, что речь идет об индексе который не обязан быть aligned. Думаю вы не вникли смысл same named partition function в понимании MS. Я сам сейчас пытаюсь вникнуть. Если вникать облом, погуглите "Msg 1908, Partition columns for a unique index must be a subset of the index key." то найдете кучу примеров обсуждений , где используются разные типы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 20:36 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!намекаете, что ноты посвященные проблемам ио в темпдб не достаточный аргумент ? Намекаю на то, что для Вас любая нота от MS, описывающая возможные узкие места с производительностью и способами оптимизации производительности чего угодно является гарантированным фактом подтверждения того, что эта проблема обязательно случиться. Как на счет: Oracle® Database Performance Tuning Guide ?! Не хилый такой документик, и в какой раздел не загляни, например... I/O Configuration and Design Тут, следуя Вашей логике: авторIf the files with high-I/O are datafiles that belong to the TEMP tablespace, then investigate whether to tune the SQL statements performing disk sorts to avoid this activity, or to tune the sorting. After the application has been tuned to avoid unnecessary I/O, if the I/O layout is still not able to sustain the required throughput, then consider segregating the high-I/O files. следует сделать вывод, что у Oracle есть проблемы с сортировкой... да и с REDO логами совсем плохо... авторIf the archiver is slow, then it might be prudent to prevent I/O contention between the archiver process and LGWR by ensuring that archiver reads and LGWR writes are separated. This is achieved by placing logs on alternating drives. For example, suppose a system has four redo log groups, each group with two members. To create separate-disk access, the eight log files should be labeled 1a, 1b, 2a, 2b, 3a, 3b, 4a, and 4b. This requires at least four disks, plus one disk for archived files ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 20:54 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
interesting Я нигде Вам ничего не доказывал про MSSQL . Ни в вопросе ни в ответе MSSQL не звучало, пока Вы не процитировали MSDN под моей цитатой. вы утверждали "Можно, если он не уникальный." в контексте спора могут ли партиции мсскл решить проблему горячего блока... interesting Думаю вы не вникли смысл same named partition function в понимании MS. если у таблицы и индекса разные функции для партиционированния, то по моему ясно как божий день, что ничего align-нового у них не получится, что бы там МС под align не понимала. далее фраза о том, что функция к тому же и не обязана быть aligned, вообще не оставляет никакого маневра ... 2pkarklin собственно я об этом и говорю, читая оракловый перфоменс гвайд и смотря на архитектуру мсскл я начинаю задаваться вопросом, а не перемножаться ли ио проблемы если бы в оракле UNDO запихнули в TEMP тайблспейс. читая аналогичный майкрософтский гвайд я вижу подтверждение своим предположениям о том, что проблемы не просто усугубятся, но перемножаться. лично мне кажется ухищрения которые вынуждена рекомендовать мс для темпдб тому доказательства. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2010, 22:04 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!interesting Я нигде Вам ничего не доказывал про MSSQL . Ни в вопросе ни в ответе MSSQL не звучало, пока Вы не процитировали MSDN под моей цитатой. вы утверждали "Можно, если он не уникальный." Я всего лишь ответил на Ваш странный вопрос Yo.! а разве можно навешивать индекс отпартиционированный по другому полю чем таблица ? Yo.! в контексте спора могут ли партиции мсскл решить проблему горячего блока... Баян :) На этот вопрос уже был дан ответ. Перечитайте еще раз тему, и обратите внимание в чем заключается горячесть блоков в контексте обсуждения, в качестве подсказки, информация содержится в цитате которую приводили Вы. Yo.! interesting Думаю вы не вникли смысл same named partition function в понимании MS. если у таблицы и индекса разные функции для партиционированния, то по моему ясно как божий день, что ничего align-нового у них не получится, что бы там МС под align не понимала . далее фраза о том, что функция к тому же и не обязана быть aligned, вообще не оставляет никакого маневра ... Слив засчитан :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2010, 00:18 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
Yo.!locky байтики считаем? неа - деньги. если к каждому полю где у меня upper() индекс висит пришлось бы дублировать поле я бы в 4гб XE редакции бы не влез. А не пробовал считать колонки с названиями SYS_* ? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2010, 20:33 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
...Было слышно, как тикают часы и капает вода из крана... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2010, 21:26 |
|
||
|
Oracle vs MS SQL vs Sybase
|
|||
|---|---|---|---|
|
#18+
SYS_NC00002$А не пробовал считать колонки с названиями SYS_* ?А не пробовал сначала жевать, а потом говорить? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. pkarklin...Было слышно, как тикают часы и капает вода из крана...Надо смеяться? P.S. А вообще забавно наблюдать, как тот, кто мало разбирается в reverse in dexes (Yo.!) обсуждает их с теми, кто в них вообще ни в зуб ногой :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2010, 21:34 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=36511614&tid=1552814]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 166ms |

| 0 / 0 |
