|
|
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Интересно, никто не пробовал решить подобную задачу на блокировочнике? На грязном чтении? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2005, 12:00 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
gardenmanИнтересно, никто не пробовал решить подобную задачу на блокировочнике? На грязном чтении? Меня убедили, что в оракле нет грязного чтения Можете привести пример когда есть? ....... Stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 11:57 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
2 Stax Он о другом, посмотри в профиль. Пытается показать что в данной задаче MS SQL круче, поскольку обеспечивает грязное чтение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 12:29 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Данную задачу блокировочники действительно решают получше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 14:37 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Грязное чтение это не решение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 15:01 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
gardenmanДанную задачу блокировочники действительно решают получше. пашутил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 15:08 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
gardenmanДанную задачу блокировочники действительно решают получше. Дык, уникальные индексы изменяются на блокировках и грязном чтении. Пользуйтесь! Поясню на сценарии. Пусть сессии С1 и С2 добавляют в уникальный индекс одинаковый ключ К. Почучаем вот что: 1. С1 insert К. Ok. 2. С2 insert К. Wait 3. С1 commit 4. С2 ORA-00001: unique constraint violated На шаге 2 С2 "видит", что в индексе присутствует ключ К, который добавила С1, но ещё не завершила транзакцию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 15:17 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
mcureenab gardenmanДанную задачу блокировочники действительно решают получше. Дык, уникальные индексы изменяются на блокировках и грязном чтении. Пользуйтесь! Поясню на сценарии. Пусть сессии С1 и С2 добавляют в уникальный индекс одинаковый ключ К. Почучаем вот что: 1. С1 insert К. Ok. 2. С2 insert К. Wait 3. С1 commit 4. С2 ORA-00001: unique constraint violated На шаге 2 С2 "видит", что в индексе присутствует ключ К, который добавила С1, но ещё не завершила транзакцию. Нужен пример индекса, какой создаете? ...... Stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 15:38 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Stax. mcureenab gardenmanДанную задачу блокировочники действительно решают получше. Дык, уникальные индексы изменяются на блокировках и грязном чтении. Пользуйтесь! Поясню на сценарии. Пусть сессии С1 и С2 добавляют в уникальный индекс одинаковый ключ К. Почучаем вот что: 1. С1 insert К. Ok. 2. С2 insert К. Wait 3. С1 commit 4. С2 ORA-00001: unique constraint violated На шаге 2 С2 "видит", что в индексе присутствует ключ К, который добавила С1, но ещё не завершила транзакцию. Нужен пример индекса, какой создаете? ...... Stax create unique index ... Ещё добавлю, что статистика Current Gets это ничто иное, как чтения текущих состояний блоков, т.е. состояний которые могут включать изменения созданые незавершёнными транзакциями. Статистика Consistent Gets это чтения блоков по состоянию на определённый момет времени, которые включают изменения только из завершенных к этому моменту времени транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 16:05 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
mcureenabcreate unique index ... Звиняйте, не точно задал вопрос, интересует как укажите по чем индекс, если грубо то по каких полях? ....... Stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 16:15 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Поскольку в задече речь идёт о триггере, то может быть не в тему. добавляем колонку: num integer; -- Номер записи с одинаковым dept и name. создаём ограничение целостности check(num between 1 and 3) -- замечу, что тип колонки integer, тоже содержит неявное ограничение, т.е. мы не можем сохранить, например 1.3. создаём ограничение целостности unique (dept, name, num) теперь в таблицу с колонками (dept, name, num) можно вставить не более трёх записей с одинаковым значением (dept, name). Как вычислить в триггере значение num, это уже другой вопрос. Один из вариантов, использовать дополнительную таблицу со счётчиком уже обсуждался тут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 16:17 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
mcureenabКак вычислить в триггере значение num, это уже другой вопрос Это не другой, а главный вопрос, имхо, пронумеровать не так просто ...... Stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 16:54 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Stax. mcureenabКак вычислить в триггере значение num, это уже другой вопрос Это не другой, а главный вопрос, имхо, пронумеровать не так просто ...... Stax Во истину, мы не ищем лёгких путей! Неужели от 1 до 3х посчитать так сложно? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Это конечно не триггерный вариант и далеко не самый оптимальный, но он тоже работает. Придумать бы, чтобы одновременно три сессии могли скоординированно получить уникальные значения num и не мешая друг другу произвести вставку... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 17:33 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
mcureenab Stax. mcureenabКак вычислить в триггере значение num, это уже другой вопрос Это не другой, а главный вопрос, имхо, пронумеровать не так просто ...... Stax Во истину, мы не ищем лёгких путей! Неужели от 1 до 3х посчитать так сложно? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Это конечно не триггерный вариант и далеко не самый оптимальный, но он тоже работает. Придумать бы, чтобы одновременно три сессии могли скоординированно получить уникальные значения num и не мешая друг другу произвести вставку... мне нравится последний абзац, мне лично придумать сложно ...... Stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 20:04 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
А вот кому решение без триггера! Чистый FBI! Elic, мой приз еще здесь? К сожалению, "скоординировать" три сессии и мне не удалось, хотя... думаю, если хорошо извратить сущность dbms_lock, то все у нас получится :) Код: 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. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 21:11 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousА вот кому решение без триггера! Чистый FBI! Elic, мой приз еще здесь? I do not think you can claim it. Your FBI is not deterministic: Код: 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. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 22:03 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Почему-то не заметил раньше этой ветки. ;( Мои несколько копеек: Задача интересная. Хотя само бизнес-правило "не иметь более n однофамильцев в одном отделе" несколько странное. Неужели, где-то это в реальности практикуется? И что делают, если появляется n+1-ый однофамилец? Его в другой отдел переводят? А как быть, если в каждом отделе уже работает n Ивановых и приходит еще один Иванов? Новый отдел создается??? ;) Тем не менее, если не задумываться над странностями бизнес-правила, -- наилучший вариант, имхо, предложил Владимир Бегун. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 22:40 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Well, somehow nobody offered INSTEAD OF trigger solution: Код: 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. where WHO_CALLED_ME is a function that reads dbms_utility.format_call_stack and retrurns calling routine name (I believe you can find source code у Кайта). SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 00:05 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
SY andrey_anonymousА вот кому решение без триггера! Чистый FBI! Elic, мой приз еще здесь? I do not think you can claim it. Your FBI is not deterministic: SY.Ну не так уж все и плохо. Просто забыл про rebuild Добавьте в ane_test_p.f следующий кусок и все заработает: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 00:16 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Sorry, I hit "post it" too early. There is a caveat. Trigger based solution, applies to future changes only (changes since trigger create time), while index applies to current data + future data. Another word, if we will create table AAA, populate it with, lets say, 5 Joe Shmoe's in department 8, and only then create view and triggers, it will not be detected. It could be considered as a disadvantage or as an advantage since it allows to implement "from now on no more более трех однофамильцев, работающих в одном отделе" rule. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 00:28 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Ну не так уж все и плохо I think it is worse than you think. Just add dbms_output to deleting part: Код: 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. As you can see FBI values for each of three rows will be: Код: plaintext 1. 2. Now lets delete row with 1/#/Q!Q/#/2: Код: plaintext 1. 2. 3. 4. 5. 6. As you can see your function wll delete wrong FBI entry 1/#/Q!Q/#/3. So index becomes logically corrupt. You can probably get away with it, since you can not use this FBI in WHERE clause anyway, but still corrupt index is a corrupt index. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 00:52 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
Actually, I overlooked a major issue with your solution. It simply will not work. Assume session A inserts a row (for simplicity lets say table is empty). That row will have index value of 1/#/Q!Q/#/1. Session A does not commit/rollback yet. Now session B tries to insert a row. Obviously, table is locked and session B waits. Now the fun part - read consistency. Since session B transaction started before Session A committed, session B will not see any changes done by session A. So when session A will commit and release the lock, session B will also try to insert index value 1/#/Q!Q/#/1 and will get unique constraint violation. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 01:12 |
|
||
|
Задачка
|
|||
|---|---|---|---|
|
#18+
:-) Код: 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. Let me repeat: "Кодирование, обход мутаций и обеспечение целостности данных при конкурентном изменении данных в таблице -- это ряд вещей, над которыми приходится задумываться решая эту и подобные ей задачи используя DIY-методы." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 01:34 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=33329324&tid=1956403]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
84ms |
get tp. blocked users: |
2ms |
| others: | 249ms |
| total: | 428ms |

| 0 / 0 |
