|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Привет всем! Пока новичок в DB2. Я имею DB2 UDB v.8.2 for Win2000 (после FixPack 7). Graeme Birchall в книге DB2 UDB V8.2 SQL Cookbook пишет в своих замечаниях к операторам UNION, INTERSECT, and EXCEPT (стр. 245): Precedence Rules When multiple operations are done in the same SQL statement, there are precedence rules: - Operations in parenthesis are done first. - INTERSECT operations are done before either UNION or EXCEPT. - Operations of equal worth are done from top to bottom. ( Выделено мною ) Смотрим далее... IBM в справочнике DB2 Universal Database SQL Reference, Volume 1 version 8.2 в главе 4. Запросы пишет в части Fullselect следующее (стр. 487): When multiple operations are combined in an expression, operations within parentheses are performed first. If there are no parentheses, the operations are performed from left to right with the exception that all INTERSECT operations are performed before UNION or EXCEPT operations. ( Выделено мною ) Я делаю следующее: Код: 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.
Теперь создаю представление и загружаю данные... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Теперь посмотрим план доступ для следующего запроса: SELECT * FROM T_V Код: 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. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211.
Из плана следует, что DB2 осуществляет доступ к таблицам не в том порядке, в котором таблицы были перечислены в представлении T_V. Для проверки выполним этот запрос: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Я заключал наборы в скобки и менял класс оптимизации ( dft_queryopt ) и делал многое другое, но это не решило проблемы. Причем самое интересное в том, что при INSERT порядок доступа тот, который я задал при создании представления, а в других операциях (SELECT, INSERT, DELETE) нет. Я считаю это достаточно неприятной проблемой, которая может в итоге привести к нежелательным последствиям в функционировании приложения!!! В связи с этим у меня несколько вопросов 1. Такая ситуация существует только в DB2 8.2 (и только у меня) или это было и в ранних версиях? Может кто-нибудь это проверить у себя и поделится здесь? 2. Может кто-нибудь порекомендовать проверенный обход этой проблемы или какое-либо решение? 3. Может кто-нибудь объяснить в чем дело? Или это все-таки "баг"? Заранее благодарю за любую помощь! С уважением, kdima71. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2004, 19:26 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
As for me, I don't see the relation between precedence rules and access plan. I would not bind SQL statement precedence to access plan. I might be wrong. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2004, 22:02 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Теперь посмотрим план доступ для следующего запроса: SELECT * FROM T_V У тебя не задан явно порядок сортировки. поэтому данные будут в том виде в каком их удобно извлечь. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 10:27 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Alexander MozhaevУ тебя не задан явно порядок сортировки. поэтому данные будут в том виде в каком их удобно извлечь. Спасибо за отклик! Еще раз повторюсь для меня важен соответствующий порядок доступа, а не порядок возвращаемых записей. Теперь смотрим план для SELECT * FROM T_V ORDER BY NODE_ID... Код: 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. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247.
Порядок доступа не изменился! P.S. Могли бы Вы реально проверить эту ситуацию у себя и проинформировать эту проверку здесь (OS, версия DB2, план доступа, код и т.д и т.п.). Заранее благодарю! С уважением, kdima71. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 10:50 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Еще такой вопрос, внутрираздельный параллелизм включен?... Может покапать в этом направлении? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 11:12 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
в плане видно что нет... по большому счету не важно в какой последовательности будут просматриваться таблицы, важно чтобы это проходило параллельно. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 11:15 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Наводящий вопросы - Почему тебе важен порядок доступа??? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 15:43 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Спасибо за проявленный интерес к моей проблеме! Nikolay KulikovНаводящий вопросы - Почему тебе важен порядок доступа??? Чтобы избежать "тупиковую" ситуацию (deadlock)!!! Теперь позвольте задать свой вопрос - Так так пока никто не поделился со мной информацией, по поводу воспроизведения моей проблемы в своем окружении и не сказал, что у него порядок доступа к таблицам совпадает с порядком, который был определен во время создания представления, то можно ли сделать вывод, что DB2 использует от версии к версии какой-то свой внутренний алгоритм ( неподвластный никому? ) в обработке наборов в UNION ALL и от этого никуда не денешься и с этим надо считаться? P.S. Повторюсь, я пока новичок в DB2, но имею достаточный опыт в Oracle, чтобы задумываться о проблемах и их решения сейчас, пока я нахожусь в статусе "студента". В скором времени меня ждет настоящая практика... С уважением, kdima71. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 16:33 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#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.
Код: 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.
T5 T4 T3 T2 T1 T6 T4 T3 T2 T1 T5 - однако закономерность налицо я полагаю что выборка из TN...T1 должна производиться в параллель, иначе и особого смысла в таком VIEW нет ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 17:03 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#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. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 17:13 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
I did not get _why_ the order of tables in a view has to be the same as in an access plan. IMHO SQL statement must not have any relations to a way data is accessed. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2004, 23:24 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Большое спасибо всем, кто попытался вместе со мной разобоаться с этой проблемой! Хочу сразу пояснить, что я не делаю трагедии из этой ситуации, но хочу заметить следующее: Так как DB2 не может обеспечить порядок доступа к таблицам, как они были перечислены в определении представления, то в случаи одновременного доступа к этим таблицам через такое представление (псевдоразделение данных с помощью UNION ALL), "писателем", который вставляет большое число новых записей (причем записи будут распределяться по нескольки таблицам) и "читателем" (причем запрос будет возвращать данные из нескольких таблиц), возможен deadlock ! Поясню, тупиковая ситуация может произойти, так как при вставке записей, DB2 будет осуществлять доступ к таблицам в том порядке как было определено в представлении, а при запросе будет использоваться совсем другой порядок! Я считаю, что это очень неприятная проблема (например, в окружении SQL Replication) и непонятно почему IВМ до сих пор не разрешил ее?! Поэтому, буду искать пути решения "походу дела" и заранее благодарю за любые идеи. С наступающим Новым Годом! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2004, 15:15 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
"Я считаю, что это очень неприятная проблема (например, в окружении SQL Replication) и непонятно почему IВМ до сих пор не разрешил ее?!" It is not a problem at all. An SQL statement has nothing to do to a physical access to a data. It is main principle of RDBMS. RDBMS can change an access plan with time for the same SQL statement. You have not relay on the physical access. The doc does not say DB2 will use the same order in access plane you use in view statement. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2004, 21:50 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
ggv"It is not a problem at all. DEADLOCK это не прoблема??? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 09:35 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
2 kdima71 почему вы так уверены что клинч возникнет?... Если вы у читателя поставите уровень изоляции UR то он не возникнет никогда. А чтобы можно было использовать UR - нужно просто правильно проектировать систему. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 10:11 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Почему просто не воспользоваться MDC???? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 12:55 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
gardenman2 kdima71 почему вы так уверены что клинч возникнет?... Моя уверенность, основана на том, что я многократно воспроизводил такую ситуацию в своем окружении и могу ее воспроизвести в любой момент для доказательства!!! При необходимости, могу представить здесь свои отчеты! gardenmanА чтобы можно было использовать UR - нужно просто правильно проектировать систему. Правильно! Я и пытаюсь, разобраться как нужно оптимально проектировать систему в DB2, которая обеспечивала бы с одной стороны высокий конкурентный доступ, а с другой непротиворечивость данных. Избегая при этом ТУПИКОВЫХ СИТУАЦИЙ. При этом надо учитывать, что будет использоваться SQL Replication. UR - держу в голове, как самый "последний", запасной вариант и возможно будет использоваться только в крайней ситуации. nkulikovПочему просто не воспользоваться MDC???? Я преследую следующие цели, используя представление с UNION ALL в SQL Replication: 1. Уменьшить взаимное влияние со стороны нескольких источников на целевой массив данных; 2. Горизонтально pазделить целевой массив данных (например по временному диапазону); 3. Обеспечить прозрачность в доступе к одному и тому же массиву данных для "читателя" и "писателя"; 4. Обеспечить возможность выполнять различные административные операции по поддержки целевого массива данных в отдельности по разделам; 5. Обеспечить возможность наращивания новых разделов (читай новых источников) без измененения в коде программ. В текущий момент, разделение данных по разделам с помощью UNION ALL в DB2, это приемлемое на мой взгляд решение, пока не появится разделение на уровне таблиц (partitioning table). Причем UNION ALL обеспечивает любой уровень вложенности (sub-partitioning) и дает возможность разбивать данные используя RANGЕ и LIST методы (в терминологии Oracle). P.S. Я буду рад, если это поможет в понимании той проблемы, которую я здесь затронул. С уважением, kdima71. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 16:19 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
честно говоря... (не знаю я что у вас за задача) .. но у меня такое ощущение что вы роете не в том направлении...:-( ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 16:44 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
looks like db2 ESE with partitioning could help. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 22:11 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
unpredictable physical access is not a problem - it is normal for rdbms. About deadlock and how to workaround - it depends from the system design and described in the doc. If to use INSERT INTO T_V (DOC_ID, NODE_ID) VALUES (1,1); COMMIT; ........................................................................................................................ INSERT INTO T_V (DOC_ID, NODE_ID) VALUES (1,9); COMMIT; instead of INSERT INTO T_V (DOC_ID, NODE_ID) VALUES (1,1),(1,2),(1,3),(1,4),(1,5),(1,6),(1,7),(1,8),(1,9); COMMIT; there is much less posibility for deadlock. For OLTP do COMMIT as soon as you can in RDBMS based on locking. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 22:37 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
I still do not see any relation between the tables order in the access plan and deadlock. Deadlock is possible regardless _any_ tables order, when more than one transaction accessing rows (row level locking) with different lock and one of them is exclusive. Deadlock is possible without UNION statement also, and I can create this situation quit easy with two connections only. And deadlock IS NOT a problem at all. Even it happened, one transaction will be rolled back with an appropriate error code. Your applications has to catch the error and repeat the transaction if need. But read the Concept, DB2 is not Oracle and has to be used differently. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2004, 06:48 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Let check the problem with deadlock. I made a small program fastly. file insert.c #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> int insert (int table, int value); void usage (char *progname){ fprintf(stderr, "usage: %s -i <instance> -d <dbname> [ -n amount of insertions, default 1 ]\n", progname); } int main (int argc, char **argv){ int c; /* for getopt and a counter for cycle */ char instance[20] = ""; char dbname[20] = ""; char env[12+20]; int amount = 1; int f; /* file descriptor */ unsigned short buf; ssize_t rd; if(argc < 3) usage(argv[0]), exit(1); while((c = getopt(argc, argv, "i:d:n:")) != -1){ switch(c){ case 'i': strncpy(instance, optarg, 20 - 1); break; case 'd': strncpy(dbname, optarg, 20 - 1); break; case 'n': if(!(amount = atoi(optarg))){ fprintf(stderr, "wrong -n argument - '%s'\n", optarg); usage(argv[0]); } break; default: usage(argv[0]); exit(1); break; } } if(instance[0] == '\0' || dbname[0] == '\0'){ usage(argv[0]); exit(1); } sprintf(env, "DB2INSTANCE=%s", instance); putenv(env); f = open("/dev/urandom", O_RDONLY); if(f == -1){ perror("Could not open /dev/urandom\n"); exit(1); } if(connect(dbname)) exit(1); for(c = 0; c < amount; c++){ rd = read(f, &buf, 2); if(rd == -1){ perror("Could not read from /dev/urandom\n"); exit(1); } if(buf < 0 ) buf *= -1; printf("%d\n", buf); /* add here a check for returned value, if it is equal -911 * we got a deadlock or lock timed out, * we can repeat a transaction */ if (buf >= 0 && buf < 6553) insert (0, buf); else if (buf >= 6553 && buf < 13106) insert (1, buf); else if (buf >= 13106 && buf < 19659) insert (2, buf); else if (buf >= 19659 && buf < 26212) insert (3, buf); else if (buf >= 26212 && buf < 32765) insert (4, buf); else if (buf >= 32765 && buf < 39318) insert (5, buf); else if (buf >= 39318 && buf < 45871) insert (6, buf); else if (buf >= 45871 && buf < 52424) insert (7, buf); else if (buf >= 52424 && buf < 58977) insert (8, buf); else if (buf >= 58977 && buf < 65535) insert (9, buf); } } file tinsert.sqc #include <stdio.h> #include <sql.h> #include <sqlenv.h> #include <sqlda.h> #include <sqlca.h> EXEC SQL INCLUDE SQLCA; int CHECK_OPER(struct sqlca *ptr, int *sqlcode) { int rc = 0; char errMessage[1024]; if (ptr->sqlcode == 0 || ptr->sqlcode == 100 ) return 0; else{ if(ptr->sqlcode < 0){ strcpy(errMessage, "Error message: "); }else strcpy(errMessage, "Warning message: "); fprintf(stderr, errMessage); sprintf(errMessage, "SQLCODE = %ld\n", ptr->sqlcode); } fprintf(stderr, "got %s\n", errMessage); rc = sqlaintp( errMessage, 1024, 80, ptr); fprintf(stderr, "rc %d\n", rc); if(rc > 0) fprintf(stderr, "got %s\n", errMessage); rc = sqlogstt( errMessage, 1024, 80, ptr->sqlstate); fprintf(stderr, "rc %d\n", rc); if(rc > 0) fprintf(stderr, "got %s", errMessage); if(ptr->sqlcode < 0){ return 1; }else return 0; } int connect (char *dbname){ int sqlcode; EXEC SQL BEGIN DECLARE SECTION; char dbAlias[20]; EXEC SQL END DECLARE SECTION; strncpy(dbAlias, dbname, 20 - 1); EXEC SQL CONNECT TO :dbAlias; if (CHECK_OPER(&sqlca, &sqlcode)) return 1; return 0; } int insert( short table, short value ){ int sqlcode; EXEC SQL BEGIN DECLARE SECTION; short doc_id; short node_id; EXEC SQL END DECLARE SECTION; doc_id = value; node_id = table; EXEC SQL insert into t_v (doc_id, node_id) values(:doc_id, :node_id); if (CHECK_OPER(&sqlca, &sqlcode)){ EXEC SQL ROLLBACK; return sqlcode; } EXEC SQL COMMIT; return 0; } Here is a db schema: #!/bin/sh . /export/home/db2inst1/sqllib/db2profile db2 connect to test; for i in 0 1 2 3 4 5 6 7 8 9 do echo $i db2 CREATE TABLE t$i \( \ DOC_ID SMALLINT NOT NULL,\ NODE_ID SMALLINT NOT NULL,\ T TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, \ CONSTRAINT t1_NODE_CHK \ CHECK \(NODE_ID = $i\)\ ENFORCED \ ENABLE QUERY OPTIMIZATION\ \); db2 -v create index idx_${i}t on t$i \(T\) allow reverse scans; done db2 CREATE VIEW t_v AS \ SELECT \* FROM t0 UNION ALL \ SELECT \* FROM t1 UNION ALL \ SELECT \* FROM t2 UNION ALL \ SELECT \* FROM t3 UNION ALL \ SELECT \* FROM t4 UNION ALL \ SELECT \* FROM t5 UNION ALL \ SELECT \* FROM t6 UNION ALL \ SELECT \* FROM t7 UNION ALL \ SELECT \* FROM t8 UNION ALL \ SELECT \* FROM t9; Let now make a test. A test box is an old one, 1996 year production, 2x300MHz. time ./insert -i db2inst1 -d test -n 10000 real 1m26.775s user 0m1.610s sys 0m1.170s we have about 116 transactions per second. in anothe xterm let run db2 "select count(*), node_id from t_v group by node_id" in a while(1) cycle, and again start time ./insert -i db2inst1 -d test -n 10000 > /dev/null 2>&1 real 1m29.503s user 0m1.390s sys 0m0.690s so we got about 112 transaction per second and no one deadlock. It's not good. Ok, let start a second time ./insert -i db2inst1 -d test -n 10000 Now we have two clients doing insertion non-stop, ASAP. Let get some stat at the same time by running db2 "select sum(doc_id) from t_v where t >= (current_time - 30 seconds)" We have now three clients, two doing insertion, one doing select, all three works asap and non-stop, and no any errors nor deadlock. Let try nselect sum(doc_id) from t_v - the result is the same. Ok, let try select doc_id, node_id from t_v where t >= (current_timestamp - 1 second) in another words get all rows last second inserted. Again there is no deadlock - it just works. I have seen about 270 rows fetched (it's about transactions per second from both clients doing insertion). The same result is if we run db2 update t_v set doc_id=doc_id+1 where doc_id!=9 and t>=(current_timestamp -1 second) Unfortunatelly, I could not get a deadlock, having four clients working simultaneously. The final test: first client doing select for rows inserted in the last second in cycle without interval; second client doing update doc_id for rows inserted in the last second in cycle again; third and fourth doing insert ASAP continuosly; For such old box, with everything are placed on a single hard disk, probably it is not bad. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2004, 21:32 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Нет, проблемка-то любопытная. Пусть транзакция Tr1 выполняет select * from t_v where... а транзакция Tr2 в это же время выполняет update t_v set ... при этом подмножества "вовлеченных" записей в Tr1 и Tr2 имеют непустое пересечение. Если t_v - это таблица, а Tr1 и Tr2 производят сканирование в разных направлениях, то в случае DB2 одна из транзакций может "подвиснуть" на блокировке (до тех пор, пока другая транзакция не завершится). К примеру, Tr1 пытается читать запись, измененную Tr2. Или (уровень изоляции Tr1 выше CS) Tr2 пытается изменить запись, прочитанную Tr1. Это - привычное дело. А вот когда t_v - это view с UNION ALL, дела обстоят сложнее. Что, если Tr1 читает сперва T1, затем T9, а T2 меняет сперва T9, затем T1? При этом уровень изоляции Tr1 выше CS (ну, или она тоже производит UPDATE)? Это - deadlock. Требуется доказать, что такого быть не может. Мне кажется, что этого действительно не может быть - план все время показывает порядок Tn-1..T1, Tn, что должно быть достаточно для предотвращения указанного мной случая. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2005, 12:59 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
"А вот когда t_v - это view с UNION ALL, дела обстоят сложнее. Что, если Tr1 читает сперва T1, затем T9, а T2 меняет сперва T9, затем T1? При этом уровень изоляции Tr1 выше CS (ну, или она тоже производит UPDATE)? Это - deadlock." I might be wrong, but deadlock it is when Tr1 reads T1 then updates T9 and Tr2 reads T9 then updates T1, isn't it? Both transactions hold a resource and wait for a resource other holds. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2005, 22:21 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
На уровнях изоляции, больших CS, остается блокировка после чтения (на строке; возможна эскалация на уровень таблицы). Пусть Tr1 в интервал времени Ti1 пытается прочитать строку t1 из таблицы T1, затем в интервал времени Ti2 строку t9 из таблицы T9, а Tr2 пытается в интервал времени Ti1 обновить t9 из T9, затем в интервал времени Ti2 строку t1 из T1. В интервал времени Ti2 транзакция Tr1 держит блокировку на t1 и не может прочитать t9 транзакция Tr2 держит блокировку на t9 и не может изменить t1 (хотя может читать) Надо посмотреть по шагам (через Spotlight от Quest Central, к примеру; все никак не соберусь) - когда происходит работа со view наподобие t_v, когда накладываются блокировки типа "intent" на таблицы - сразу после начала запроса или непосредственно при обращении к таблице? Если первое, то, наверное, уже тем самым мы от deadlock'а гарантированы. Если второе, то тогда надо надеяться на оптимизатор. Хотя как вам случай create view t_v1 as select * from t1 union all ... union all select * from t9 create view t_v2 as select * from t9 union all ... union all select * from t1 ? Впрочем, кем надо быть, чтобы в своей программе сотворить такое? ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 01:29 |
|
|
start [/forum/topic.php?fid=43&msg=32848786&tid=1606029]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 310ms |
total: | 435ms |
0 / 0 |