Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
тута давеча спор был, по поводу нужности и ненужности нетранзакционных таблиц, а также нужности/ненужности сессионных временных таблиц (см. Сайбес, спр. ASCRUS). для проверки нужности (или ненужности) написал маленький скрипт, упрощенный вид расчета сальдо по счетам, исходя из начальных остатков и движения по ДТ/КТ. delete vs. truncate проверяется легко, стоит только заменить :-) а вот logged vs. nonlogged - увы, в MS SQL нельзя создать нетранзакционную таблицу. обошелся тем, что для проверки запускал в tempdb, там лог не сразу пишется на диск, так что хоть немного, но его влияние уменьшилось. скрипт по созданию Код: 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. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. скрипт для проверки Код: 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. получилось так обычная база: TimeWithTruncate=2453, TimeWithDelete=3920 tempdb: TimeWithTruncate=1736, TimeWithDelete=1923 т.е. применяя сесионные временные таблицы и nonlogged таблицы я бы мог получить выигрышь по скорости в 3920/1736=2.25 раза. Вопросы по нужности этих фич будут? -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 16:18 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
Ну тогда уже надо рассмотреть и табличные переменные, которые не являются транзакционными, данные хранятся в tempdb. Я думаю, несложно их будет их подставить в эти скрипты. Какие будут результаты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 16:58 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
AAron wrote: > Ну тогда уже надо рассмотреть и табличные переменные, которые не > являются транзакционными, данные хранятся в tempdb. Я думаю, несложно их > будет их подставить в эти скрипты. > > Какие будут результаты? табличные переменные рассматривать не буду, даже в принципе :-) поелику они всё-таки транзакционные, это раз. а во вторых область видимости у них не-ага, меж процедур их не передашь. а в третьих, набор индексов на них весьма убог, однако :-( -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 17:07 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
Т.е. если есть что-то, что не укладывается в теорию, то значит этого нет? С индексами, конечно, засада. Можно рулить только в пределах PK. Давайте все же рассмотрим. Таблички действительно нетранзакционные. Простой пример: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 17:53 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
AAron wrote: > Т.е. если есть что-то, что не укладывается в теорию, то значит этого > нет? С индексами, конечно, засада. Можно рулить только в пределах PK. > про неукладку в теорию - не понял, тупой сегодня... чего нет, кого нет? > Давайте все же рассмотрим. Таблички действительно нетранзакционные. > Простой пример: > > set nocount on > go > declare @t table (id int) > begin tran > insert into @t values (*1*) > select * from @t > rollback tran > select * from @t > go > set nocount off > go > > id > ----------- > *1* > > id > ----------- > *1* > давайте-давайте.... Код: plaintext 1. 2. 3. 4. есть. как эту атомарность организовать без лога - ума не приложу. скажем так, наверное, нетранзакционность - не очень правильное слово, правильнее наверное нелоггируемая. потому как лог таки есть. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 17:59 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
lockyатомарность на уровне оператора там есть. как эту атомарность организовать без лога - ума не приложуНе каждый лог должен называться transaction log ;) В смысле - для табличных переменных может быть организован собственный лог, отбрасываемый после выполнения оператора. Вариантов реализации - уйма ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 22:56 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
hvlad wrote: > locky > атомарность на уровне оператора там > есть. как эту атомарность организовать без лога - ума не приложу > > Не каждый лог должен называться transaction log ;) > В смысле - для табличных переменных может быть организован собственный > лог, отбрасываемый после выполнения оператора. Вариантов реализации - уйма во-во!!! Но таки организован! а он ить бывает и не нужен... -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2005, 23:19 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
lockyкак видим, табличка пустая, т.е. атомарность на уровне оператора там есть.Разумеется есть, оператор либо выполняется полностью, либо нет. Выполнение его наполовину в лучшем случае вызовет нервный смех. Насколько помню, есть СУБД, где это не так, и тогда, например, оператор Код: plaintext К данному случаю транзакционный лог не имеет никакого отношения. Сначала формируется выборка для вставки, а затем она проверяется на соответствие ограничениям, в частности, NOT NULL. Вы можете это увидеть, если включите оценочный план, но при попытке посмотреть реальный, Вы не увидите запроса вставки, так как ограничения проверяются до реальной вставки данных, а ее не будет, до нее просто не дойдет, и все закончится на этапе проверки входных данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 00:10 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
ChAоператор либо выполняется полностью, либо нет. Выполнение его наполовину в лучшем случае вызовет нервный смех. Насколько помню, есть СУБД, где это не так, и тогда, например, оператор Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 00:24 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
hvladИ где тут а) неатомарность и\или б) выполнение наполовину ?В данном примере неатомарность заключается в том, что SELECT "видит" данные, которые появляются в процессе вставки, т.е., оператор Код: plaintext В дальнейшем, не хотелось бы обсуждать верность поведения, которое зафиксировано, если правильно помню, в стандартах ANSI SQL. Смысл топика заключается несколько в ином. Кстати, даже не помню, в каком из серверов такой казус возможен, посему просьба не воспринимать его упоминание как "наезд" на эту СУБД или ее адептов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 00:56 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
ChA hvladИ где тут а) неатомарность и\или б) выполнение наполовину ?В данном примере неатомарность заключается в том, что SELECT "видит" данные, которые появляются в процессе вставкиДа, вечно я про это забываю - я обычно думаю об атомарности тр-ции, а не оператора ;) ChAВ дальнейшем, не хотелось бы обсуждать верность поведения, которое зафиксировано, если правильно помню, в стандартах ANSI SQL. Смысл топика заключается несколько в ином. Кстати, даже не помню, в каком из серверов такой казус возможен, посему просьба не воспринимать его упоминание как "наезд" на эту СУБД или ее адептов.Ок, конечно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 01:18 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
интересный вопрос... разве атомарность операции зависит от лога, точнее лога транзакций? Собственн ChA уже ответил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 10:35 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
ChA wrote: > Кстати, упомянутый locky пример, если бы такое было возможно в MS SQL, > наверняка привел бы к тому, что в таблицу не вставилась только запись со > значением NULL в поле, что, IMHO, было бы неверно. ну, разве что имхо. как мне кажется, верно то, что хочет разработчик :-) Конечно, в примере есть абсолютно неправильная ситуация, но он (пример) нужен был для того чтобы продемонстрировать атомарность стэйтмента. Просто хотелось бы мне знать, как много людей ощущают потребность откатывать изменения во временных таблицах при проведении каких-либо расчетов в случае возникновения ошибки. Как мне кажется, большая часть просто рапортует ошибку и выходит. В отчетах, к примеру. да мало ли где еще при расчетах. думаю, мало кого беспокоит содержимое # таблиц в случае ошибки. А лог для них ведется, однако. противненько. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 11:34 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
для tempdb лог-транзакций вообще-то свой. tempdb как правило лежит на "скоростном" устройстве, если с ней идет интенсивная работа. А лог можно засунуть и на ramdrive. В случае краша или остановки сервера, все равно tempdb умрет. Но вообще, я просил просто выполнить те же действия для табличных переменных, чтобы можно было сравнить числа А наличие нетранзакционных таблиц - было бы неплохо, конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 12:39 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
AAron wrote: > для tempdb лог-транзакций вообще-то свой. tempdb как правило лежит на > "скоростном" устройстве, если с ней идет интенсивная работа. > А лог можно засунуть и на ramdrive. В случае краша или остановки > сервера, все равно tempdb умрет. > на рам-драйв? типун вам на п... в общем, не надо так... а свой лог - это да, пишется он куда реже, чем ля обычной базы.. доказанно занусси. > > > Но вообще, я просил просто выполнить те же действия для табличных > переменных, чтобы можно было сравнить числа там по условиям задачи не покатят тэйбл-вары, но я померяю > А наличие нетранзакционных таблиц - было бы неплохо, конечно. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 12:48 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
2locky - лог tempdb на рам-драйв а не основной базы. Но вообще, эта экзотика. В промышленных решениях я так не делал. Хотя перенос всей БД (2ГБ) на RAMDRIVE давал в связке с сервером приложений прирост в скорости от 30% до 50% в зависимости от выполняемых действий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 13:16 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
AAron wrote: > 2locky - лог tempdb на рам-драйв а не основной базы. да я уж как-то и сам это понимаю :-) > Но вообще, эта экзотика. В промышленных решениях я так не делал. Хотя > перенос всей БД (2ГБ) на RAMDRIVE давал в связке с сервером приложений > прирост в скорости от 30% до 50% в зависимости от выполняемых действий. хм... интересно. но стрёмно. -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 13:22 |
|
||
|
logged tables vs. nonlogged & delete vs. truncate
|
|||
|---|---|---|---|
|
#18+
lockyну, разве что имхо. как мне кажется, верно то, что хочет разработчикА это, полагаю, Ваше IMHO. "Разрабочики" иногда хотят, мягко говоря, очень странного :) lockyКонечно, в примере есть абсолютно неправильная ситуация, но он (пример) нужен был для того чтобы продемонстрировать атомарность стэйтмента.Возможно неправ, но мне показалось, что Вы пытались доказать наличие транзакционного лога там, где он напрочь не нужен и отсутствует. lockyПросто хотелось бы мне знать, как много людей ощущают потребность откатывать изменения во временных таблицах при проведении каких-либо расчетов в случае возникновения ошибки. Как мне кажется, большая часть просто рапортует ошибку и выходит. В отчетах, к примеру. да мало ли где еще при расчетах. думаю, мало кого беспокоит содержимое # таблиц в случае ошибки. А лог для них ведется, однако.Согласен, что как "фича", возможно и не помешала бы, хотя не уверен, что в реальности Вы получили бы упомянутый Вами потрясающий прирост производительности. Доступ к tempdb, насколько понимаю, и так оптимизирован по самое не хочу. Вам ни о чем не говорит то, что сервер пользует ее для разного рода worktable ? P.S. Вообще-то, не понимаю, что делает этот топик в форуме "Сравнение СУБД". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2005, 14:53 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33318159&tid=1553761]: |
0ms |
get settings: |
6ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 176ms |
| total: | 322ms |

| 0 / 0 |
