|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Позволяет ли DB2 7.2 разбить большую таблицу на разделы и как это сделать? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2003, 12:55 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
О каких, собственно, разделах идет речь? Мне идет на ум две вещи: 1) DB2 EEE (теперь, в v8 - ESE), кластер shared nothing. Определяется partitioning key, по хеш-значению от него данные попадают на тот или иной узел распределенной по серверам базы. 2) Многомерная кластеризация - но это только в v8. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2003, 16:09 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
На самом деле есть еще INSERT в UNION ALL View. Некая форма Range Partitioning. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2003, 18:38 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Ну, это снова в восьмерке (причем появляется с каким-то фикспаком?). ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2003, 10:20 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Под разбивкой я подразумевал следующее. В Оракле с 8 версии существует возможность создания отдельных физических мест хранения данных при едином их логическом имени. Т.е. можно разбить таблицу с 10 млн. записей на 5 таблиц по 2 млн., что существенно увеличит производительность. При этом логически считается, что это одна таблица, а запросы оптимизируются самим Ораклом. То же самое можно сделать и в MS SQL. Там есть возможность создавать горизонтально секцированные представления. Что по сути преследует ту же цель, но решается по другому. Есть ли что-то подобное в DB2 (я думаю, что есть) ? А если нет, то как такая задача решается средствами DB2 ? Заранее спасибо за все ответы. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2003, 11:20 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Range Partitionin table в DB2 UDB нет в DB2/390 есть. Сколько у тебя записей в таблице что бы начинать обэтом думать, может сначала все таки над plaement поработать???? Опять же есть INSERT во VIEW c UNION ALL. Когда запись вставляет и определяется в какую таблиц она должна попасть. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2003, 14:53 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Ну, я подозревал что-то подобное, но для 7-ки - никак (если не вспоминать про DB2 EEE), кроме как ручным способом (самостоятельно создать таблицы и модифицировать приложение так, чтобы оно вставляло и выбирало, куда вставлять, само или через SP в нужную). Для моих приложений, кстати, достаточно простого reorg'а с нужной упорядоченностью по ночам и index only access. Многомерная кластеризация (для впихивания целого диапазона - generated поле, которое этому диапазону сопоставляет единичное значение), вставлябельное view с Union all и триггеры INSTEAD - в восьмерке (бр-р-р, память слабая, может, INSTEAD уже в 7.2 были? вряд ли). ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2003, 15:52 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
У меня таблица, в которую добавляются данные и никогда не будут удалятся. Таблица увеличивается на 5 млн. записей ежегодно. При этом старые данные также могут понадобиться. :((( ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2003, 16:09 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Виктор, INSERT в UNION ALL view работает не как Instead of trigger. Там используется некоторый dynamic dispatch. Это фича 8-ки Кстати помоему UPDATE and DELETE на UNION ALL view были в 7-ке. Так же в 8-ке появились многомерные индексы и INSTEAD OF триггеры. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2003, 16:21 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Я отлично знаю, что INSERT на VIEW с UNION ALL работает не так, как с триггерами INSTEAD, но и тем, и другим можно добиться желаемого результата - вставку записи в одну и только одну таблицу, выбранную по какому-то условию. Что касается DELETE и UPDATE, это, по-моему, еще во второй версии DB2 /Common Server работало, а может, и в первой. Сейчас придумал, кстати, решение для 7.2 "через задницу" - вставка в обычную таблицу, где триггер AFTER INSERT вставляет данные в выбранную другую таблицу, а затем немедленно удаляет из своей. Для данных APPEND ONLY естественнее и удобнее пользоваться MDC (многомерной кластеризацией). Однако я не уверен в необходимости (полезность - да, а необходимость - нет) всего этого; подумаешь, пять лимонов в год ;-), да здравствует index only access. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2003, 12:52 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
В документации по поводу INSERT во VIEW c UNION ALL сказано следующее: 1)Для производных таблиц объединения с несколькими псевдонимами в условии FROM разрешено только чтение. 2) Для производных таблицы объединения с одним псевдонимом в условии FROM может быть разрешена и запись. Но остался один не решенный вопрос. Если у меня данные в таблице сгрупированы по какому-то признаку, например по времени. Будет ли DB2 просматривать характеристики всех таблиц, входящих в представдение на предмет того, что записи, удовлетворяющие условию оборота WHERE, могут находится только в одной таблице? Т.к. смысла просматривать остальные нет. Пример: SELECT * FROM TRADERS WHERE TRADEDATE BETWEEN '1/9/2001' AND '1/10/2001' Все записи, удовлетворяющие WHERE находятся в таблице TRADE_010901. Было бы хорошо, что бы ядро запросило только эту таблицу, не затрагивая остальных, входящих в представление. Это бы увеличило скорость обработки запроса. Умеет ли это DB2? Если нет, то INSERT во VIEW c UNION ALL не рашает проблемы. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2003, 13:41 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
AlexS9 А слабо попробовать??? Конечно распараллелит. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2003, 13:55 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Хм. Очень уж оптимистично. Для начала, я не понял, чью документацию процитировал AlexS9, ибо непонятно, что есть "запись" ("разрешена и запись"), ибо речь могла идти и об INSERT, и об UPDATE (да и весь отрывок совершенно непонятен; уж лучше бы он читал и цитировал английский оригинал). Далее, запросы с BETWEEN нередко тяжело оптимизировать. Вот если бы было поле ymTRADEDATE integer not null generated as (year(tradedate)*100+month(tradedate)) и вместо TRADEDATE BETWEEN '1/9/2001' AND '30/09/2001' (скорее всего именно это имелось в виду, а вовсе не TRADEDATE BETWEEN '1/9/2001' AND '1/10/2001' ) было бы ymTRADEDATE = 200109 то я был бы более спокоен - некоторый толк был бы и для старых версий DB2, а не только 8-ки. Догадается ли оптимизатор 8-ки, что если в TRADE_200108 стоит constraint(TRADEDATE BETWEEN '1/8/2001' AND '30/08/2001'), в TRADE_200109 стоит constraint(TRADEDATE BETWEEN '1/9/2001' AND '30/09/2001'), а в TRADE_200110 имеется constraint (TRADEDATE BETWEEN '1/10/2001' AND '31/10/2001'), то при WHERE TRADEDATE BETWEEN '20/8/2001' AND '10/09/2001' надо запрашивать только первые две? Лично я как-то сомневаюсь. Все это надо проверять экспериментально... ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2003, 14:49 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#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. 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. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2003, 15:16 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
"Оптимизированный план доступа" для select * from xxx where td between '2001-03-07' and '2001-05-05' в DB2 8.1.3 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Как видим, все хорошо. Интересно, что получится в 7-ке. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2003, 15:22 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Можно ли поднять тему опять? Такое вот разбиение делаеться для повышения производительности путем снижения I/O. Ну по поводу MDC и view with UNION ALL уже сказали (возможно последнее добавилось в V7.x при fixpack?) А вот что по поводу разбиения таблицы по контейнерам? конечно же, это ни в коей мере не то же, что и первые два "путя", но всё таки? Создание таблицы с индексами на отдельном tablespape из нескольких контейнеров, самой таблицы на другой tablespace из нескольких контейнеров, с обязательным условием чтобы ни доступ к tablespace'ам не пересекался, ни доступ к контейнерам внетри tablespace. Ну там разные диски, разные контроллеры. Индексы - на один контроллер, данные - на другой, и контейнеры по дискам. Таким путем можно здорово сократить I/O.... ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2003, 22:26 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Ну это само собой разумеещееся. Положить табличные TBSP, индексные TBSP и журналы транзакций в на разные диски контроллеры. Опять же стоит учитывать размеры extent'ов, prefetch size. Например не правильно сконфигурировав extents, prefetch size очень легко просадить Shark. Все очень сильно зависит от конфигурации дисковой подсистемы Но одно правило можно наверно всегда надо учитывать. Большие таблицы имеет смысл класть в отдельные TBSP от мелких и назначать разные буфферные пулы. Если все будет лежать в одной куче то страницы мелких таблиц будут постоянно вымываться из буфферпула и следовательно постоянно будет наличие direct io что не есть good. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2003, 11:49 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Кстати. раз уж extents & prefetch size затронули - где бы почитать про искусство их выбора? Я что-то конкретно таких рекомендаций и не помню. А ведь действительно - важнейшие параметры. Ну про bufferpools - так их НЕиспользование пожалуй надо считать дурным тоном :) Уж коли дадена такая возможность, то упускать ее :) Помню, когда sybase воплотил named pools, то стоко радости было :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2003, 11:59 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Нашел заметки после одного из проектов (это правда про Shark, но для других систем тоже самое) Adjust Extent Size to ESS stripe size 1) ESS stripe granularity is 32 KB (6 x 32 = 192) 2) Selecting a multiple of 32 KB makes sure that multiple ESS disks are used within a rank for DB2 big block I/O/prefetch 3) If Extent Size is less than the full array width, ESS sequential prefetch might kick in to keep all disks busy ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2003, 12:54 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Нельзя ли расшифровать акроним ESS ? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2003, 13:24 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Enterprise Storage Server. Это Shark. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2003, 14:20 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Где-то я уже это читал - что Extent size должен быть кратным размеру strip - Точно! Ну как же - в рекомендации по использованию RAID в документации IBM DB2! Гмм, я немного не про то спрашивал - не про зависимость Extent size от характеристик устройства хранения, а прор зависимость от храняхихся данных - ну там от длинны строки в таблице - неужели нет таких зависимостей? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2003, 17:23 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Хотя длина строки здесь не при чём. Extent size это ведь кол-во страниц база пишет в контейнер прежде чем переключиться на другой контейнер. Так вот именно если без RAID - зависит ли от чего этот параметр? Как он влияет на I/O - вот что бы почитать. Или ни от чего не зависит и ставить по умолчанию? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2003, 17:32 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Если у тебя нет RAID но есть 2 диска на которых лежит ТБСП ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2003, 19:05 |
|
|
start [/forum/topic.php?fid=43&msg=32328399&tid=1606420]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 169ms |
0 / 0 |