Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsa Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Без NONRECOVERABLE видал веселуху - табличному пространству позарез хочется забекапиться после LOAD'а. Но с NONRECOVERABLE всё всегда ОК. Это да, на тех БД, что я создавал тоже не было проблем, но вот на продуктивной БД и ее копиях проблемы периодически проявлятся. Я вначале думал, что это результат множественной миграции БД, начиная с 7 версии, и пересоздав TS, проблема исчезнет, но она не исчезла. И с nonrecoverable и с copy yes периодически БД подвисает на 0.5-2 часа, потом нормально грузит. Что интересно, даже если неправильно указать таблицу, то все равно вначале повиснет, а потом выдаст ошибку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2016, 16:21 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-seMark Barinsteindb2_parallel_io=* (т.е. 6) для Storwize в IBM PDOA. У вас очень большое значение. здесь немного не понял, вариант а)db2_parallel_io=* или б)db2_parallel_io=*.6Если это не ошибка у вас, то такое значение через точку вообще неправильно. Надо через двоеточие. DB2_PARALLEL_IO=* DB2_PARALLEL_IO=*:6 http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005658.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2016, 16:40 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-seИ с nonrecoverable и с copy yes периодически БД подвисает на 0.5-2 часа, потом нормально грузит. Что интересно, даже если неправильно указать таблицу, то все равно вначале повиснет, а потом выдаст ошибку. Онлайн-бекап одновременно с этим не делался? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2016, 21:17 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se... При большой выборке, как было указано вначале, индекс не используется, а если и используется (на граничных условиях) то приводит, как правило, к увеличению общего времени выборки. Таблица имеет уникальный кластерный индекс по 3 первым полям (bigint,date,bigint), соответственно. Здесь немного статистики. ... Практически бесполезна, когда плана и многого другого важного мы так и не увидели. Если ведущая таблица "большая" и фуллскан идёт по ней, кластерный индекс не особо интересен. use-seОтносительно маленькой таблицы, то она каждый день содержит новые данные и после каждого ETL чистится. Я не вижу, что с ней можно сделать, там всего 1 поле (bigint). Относительно: >>Большую таблицу надо бы попробовать организовать по MDC (с1). буду пробовать, но немного страшновато по следующим причинам: 1. Уникальность первичного ключа - это 3 поля, следовательность размерность будет 3? насколько вырастет потребность в дисковом пространстве? Положим Код: sql 1. 2. 3. и b.c1, b.c2, b.c3 - ключ на b. Разумеется, MDC по b.c1, b.c2, b.c3 - тяжёлая ошибка, ибо каждая запись займёт отдельный экстент. Смысл может иметь только MDC по меньшему числу колонок, и, скорее всего, только по c1. И то польза будет не обязательно. Надо, чтобы 1) для каждого уникального c1 было "много" записей в b Код: sql 1. 2. т.е. чтобы отношение x1/x2 было "большим"; чем оно больше, тем меньше пространства уйдёт впустую. 2) чтобы маленькая таблица была "ведущей" в запросе, a la для каждой строки small_tab s .. искать строки в big_tab b по условию b.c1=s.c1 .. конец цикла 3) и чтобы в результате только часть строк big_tab требовалась, а не все они; чтобы Код: sql 1. 2. и Код: sql 1. 2. 3. 4. 5. 6. 7. давали "серьёзно" различающийся результат 2. пока не имею практики использования (почитать, конечно же почитаю и попробую), но насколько сложны эти MDC в обслуживании? Вроде бы ничего сложного. Впрочем, и возможностей маловато (по сравнению с ораклячьим табличным партишионированием). 3. я так понял стоит попробовать именно авторORGANIZE BY -- Groups rows with similar values on multiple dimensions in the same table extent. This concept is known as multidimensional clustering (MDC). а не авторPARTITION BY -- Groups rows with similar values of a single dimension in the same data partition. This concept is known as table partitioning. Здесь MDC напрашивается. Но у Оракля, например, MDC нет, но ораклисты обходятся табличным партишионированием. Смысл же простой - надо побить таблицу на секции, чтобы фуллсканить не всю таблицу, а только некоторые секции, и так, чтобы оптимизатор понял выгоду. Хотя в данной задаче табличное партишионирование довольно неудобно, и я не уверен вообще, что DB2-шное табличное партишионирование справится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2016, 21:51 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinЕсли это не ошибка у вас, то такое значение через точку вообще неправильно. Надо через двоеточие. По факту стоит не точка, а запятая, что не меняет сути - все равно ошибка, поправил Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 12:29 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsaОнлайн-бекап одновременно с этим не делался? нет не делался Victor MetelitsaПрактически бесполезна, когда плана и многого другого важного мы так и не увидели. Если ведущая таблица "большая" и фуллскан идёт по ней, кластерный индекс не особо интересен. Прошу прощения, я должен был с самого начала приложить планы запросов, но подумал, что и так все понятно. Вот планы, если интересно: D:\scripts>db2expln -d russiadb -o d:\tmp\rows_all.txt -g -q "SELECT h.c1_id, h.c2_HISTORY_DATE, h.PAY_STATUS FROM sh1.big_tab h, sh2.small_tab l WHERE h.c1_id = l.c1_id WITH UR" DB2 Universal Database Version 9.7, 5622-044 (c) Copyright IBM Corp. 1991, 2009 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL and XQUERY Explain Tool ******************** DYNAMIC *************************************** ==================== STATEMENT ========================================== Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 5 Partition Parallel = No Intra-Partition Parallel = No SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM", "DB2ADMIN" Statement: SELECT h.c1_id, h.c2_HISTORY_DATE, h.PAY_STATUS FROM big_tab h, small_tab l WHERE h.c1_id =l.c1_id WITH UR Statement Isolation Level = Uncommitted Read Section Code Page = 1251 Estimated Cost = 236238336,000000 Estimated Cardinality = 169059488,000000 Access Table Name = big_tab ID = 8,4 | #Columns = 3 | May participate in Scan Sharing structures | Scan may start anywhere and wrap, for completion | Scan can be throttled in scan sharing management | Relation Scan | | Prefetch: Eligible | Isolation Level: Uncommitted Read | Lock Intents | | Table: Intent None | | Row : None Nested Loop Join | Access Table Name = small_tab ID = 40,15 | | Index Scan: Name = small_tab_INDEX ID = 1 | | | Regular Index (Not Clustered) | | | Index Columns: | | | | 1: c1_id (Ascending) | | #Columns = 0 | | Single Record | | Fully Qualified Unique Key | | #Key Columns = 1 | | | Start Key: Inclusive Value | | | | | 1: ? | | | Stop Key: Inclusive Value | | | | | 1: ? | | Index-Only Access | | Index Prefetch: None | | Isolation Level: Uncommitted Read | | Lock Intents | | | Table: Intent None | | | Row : None Return Data to Application | #Columns = 3 End of section Optimizer Plan: Rows Operator (ID) Cost 1,69059e+008 n/a RETURN ( 1) 2,36238e+008 | 1,69059e+008 n/a NLJOIN ( 2) 2,36238e+008 / \---\ 5,24234e+009 * n/a | TBSCAN 6,47055e+006 ( 3) Index: 1,56039e+008 sh2 | small_tab_INDEX 5,24234e+009 n/a Table: sh1 big_tab ---------------------------------------------------- D:\scripts>db2expln -d russiadb -o d:\tmp\rows_10only -g -q "SELECT c1_id, c2_HISTORY_DATE, PAY_STATUS FROM big_tab WHERE c1_id in (select c1_id from small_tab fetch first 10 rows only) WITH UR" DB2 Universal Database Version 9.7, 5622-044 (c) Copyright IBM Corp. 1991, 2009 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL and XQUERY Explain Tool ******************** DYNAMIC *************************************** ==================== STATEMENT ========================================== Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 5 Partition Parallel = No Intra-Partition Parallel = No SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM", "DB2ADMIN" Statement: SELECT c1_id, c2_HISTORY_DATE, PAY_STATUS FROM big_tab WHERE c1_id in (select c1_id from small_tab fetch first 10 rows only) WITH UR Statement Isolation Level = Uncommitted Read Section Code Page = 1251 Estimated Cost = 972,537354 Estimated Cardinality = 261,275208 Access Table Name = small_tab ID = 40,15 | #Columns = 1 | May participate in Scan Sharing structures | Scan may start anywhere and wrap, for completion | Scan can be throttled in scan sharing management | Relation Scan | | Prefetch: Eligible | Isolation Level: Uncommitted Read | Lock Intents | | Table: Intent None | | Row : None Nested Loop Join | Piped Inner | Access Table Name = big_tab ID = 8,4 | | Index Scan: Name = big_tab_PK ID = 1 | | | Regular Index (Clustered) | | | Index Columns: | | | | 1: c1_id (Descending) | | | | 2: c2_HISTORY_DATE (Descending) | | | | 3: STREAM_ID (Descending) | | #Columns = 0 | | #Key Columns = 1 | | | Start Key: Inclusive Value | | | | | 1: ? | | | Stop Key: Inclusive Value | | | | | 1: ? | | Index-Only Access | | Index Prefetch: None | | Isolation Level: Uncommitted Read | | Lock Intents | | | Table: Intent None | | | Row : None | | Sargable Index Predicate(s) | | | Insert Into Sorted Temp Table ID = t1 | | | | #Columns = 1 | | | | #Sort Key Columns = 1 | | | | | Key 1: (Ascending) | | | | Sortheap Allocation Parameters: | | | | | #Rows = 27,000000 | | | | | Row Width = 20 | | | | Piped | | | | Duplicate Elimination | Sorted Temp Table Completion ID = t1 | List Prefetch Preparation | | Access Table Name = big_tab ID = 8,4 | | | #Columns = 3 | | | RID List Fetch Scan | | | Fetch Using Prefetched List | | | | Prefetch: 2 Pages | | | Isolation Level: Uncommitted Read | | | Lock Intents | | | | Table: Intent None | | | | Row : None | | | Sargable Predicate(s) | | | | #Predicates = 1 Return Data to Application | #Columns = 3 End of section Optimizer Plan: Rows Operator (ID) Cost 261,275 n/a RETURN ( 1) 972,537 | 261,275 n/a NLJOIN ( 2) 972,537 /-/ \-\ 10 26,1275 n/a n/a TBSCAN FETCH ( 3) (--) 38146,2 95,3037 | / \ 6,47055e+006 26,1275 5,24234e+009 n/a n/a n/a Table: RIDSCN Table: sh2 ( 5) sh1 small_tab 51,4576 big_tab | 26,1275 n/a SORT ( 6) 51,4571 | 26,1275 n/a IXSCAN ( 7) 51,4532 | 5,24234e+009 Index: sh1 big_tab_PK Victor MetelitsaПоложим Код: sql 1. 2. 3. и b.c1, b.c2, b.c3 - ключ на b. Разумеется, MDC по b.c1, b.c2, b.c3 - тяжёлая ошибка, ибо каждая запись займёт отдельный экстент. Смысл может иметь только MDC по меньшему числу колонок, и, скорее всего, только по c1. И то польза будет не обязательно. Надо, чтобы 1) для каждого уникального c1 было "много" записей в b Код: sql 1. 2. т.е. чтобы отношение x1/x2 было "большим"; чем оно больше, тем меньше пространства уйдёт впустую. Получается, чтобы использовать MDC нам придется отказаться от уникальности первичного ключа и вместо (с1,с2,с3) использовать индекс по c1. На уровне БД я проблем не виду, а вот со стороны софта придется смотреть. Victor Metelitsa2) чтобы маленькая таблица была "ведущей" в запросе, a la для каждой строки small_tab s .. искать строки в big_tab b по условию b.c1=s.c1 .. конец цикла Написать процедуру, которая будет по курсору на маленькую таблицу выбирать построчно из большой? Попробую, хотя что то мне подсказывает, что лучше не будет, но спасибо за совет. Victor Metelitsa3) и чтобы в результате только часть строк big_tab требовалась, а не все они; чтобы Код: sql 1. 2. и Код: sql 1. 2. 3. 4. 5. 6. 7. давали "серьёзно" различающийся результат авторпропустил... Вроде бы ничего сложного. Впрочем, и возможностей маловато (по сравнению с ораклячьим табличным партишионированием). Здесь MDC напрашивается. Но у Оракля, например, MDC нет, но ораклисты обходятся табличным партишионированием. Смысл же простой - надо побить таблицу на секции, чтобы фуллсканить не всю таблицу, а только некоторые секции, и так, чтобы оптимизатор понял выгоду. Хотя в данной задаче табличное партишионирование довольно неудобно, и я не уверен вообще, что DB2-шное табличное партишионирование справится. Большое спасибо за детальное описание и советы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 12:58 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
весело у вас тут. неделя разговоров о высоком, а у него поблочно нестед лупом долбит :D use-se, просто добейся hash-join. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 19:21 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-seПолучается, чтобы использовать MDC нам придется отказаться от уникальности первичного ключа и вместо (с1,с2,с3) использовать индекс по c1. На уровне БД я проблем не виду, а вот со стороны софта придется смотреть. Если я правильно понимаю то, что вы написали, то вы всё ещё не понимаете, что такое MDC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 19:24 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-seНаписать процедуру, которая будет по курсору на маленькую таблицу выбирать построчно из большой? Попробую, хотя что то мне подсказывает, что лучше не будет, но спасибо за совет. Ничего подобного я не советовал. Я описывал (в меру своего понимания), как DB2 исполняет запрос. Вообще, вы бы лучше Льюиса почитали. Пусть про Oracle, пусть долго, но очень полезно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 19:28 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
[quot use-se] Прошу прощения, я должен был с самого начала приложить планы запросов, но подумал, что и так все понятно. [quot] Понятно только, что возможно минимум два плана, а на самом деле больше. И желательно fixed-шрифтом, иначе совсем ничего не понять. Вот так: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 19:32 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Ну, MDC по h.c1_id ещё более напрашивается. Второй запрос им воспользуется наверняка (хотя, за вид, он и так должен быть быстрым), первый... ну, наверное, оптимизатор догадается, а если нет, то надо будет как-нибудь заставить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 19:44 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se, Желательно выполнить: db2 "explain all with snapshot for select ..." db2exfmt -d mydb -1 -o myplan.txt Также дайте вывод: db2set -all И какие типы данных полей, по которым идёт соединение таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 21:00 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark Barinsteinuse-se, Желательно выполнить: db2 "explain all with snapshot for select ..." db2exfmt -d mydb -1 -o myplan.txt Также дайте вывод: db2set -all И какие типы данных полей, по которым идёт соединение таблиц. Добрый день. Извиняюсь за зедержку. У меня такое чувство , что мое направление движения было в самом начале неверным как и вопрос, нус бывает, прошу понять и простить. Типы полей: SMALL_TAB.C1_ID BIGINT, BIG_TAB.C1_ID BIGINT BIG_TAB.С1_HISTORY_DATE DATE BIG_TAB.PAY_STATUS SMALLINT Информация по нидексам: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Первый запрос 10 строк: Код: 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. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512. 513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 547. 548. 549. 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563. 564. 565. 566. 567. 568. 569. 570. 571. 572. 573. 574. 575. 576. 577. 578. 579. 580. 581. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737. 738. 739. 740. 741. 742. 743. 744. 745. 746. 747. 748. 749. 750. 751. 752. 753. 754. 755. 756. 757. 758. 759. 760. 761. 762. 763. 764. 765. 766. 767. 768. 769. 770. 771. 772. 773. 774. 775. 776. 777. 778. 779. 780. 781. 782. 783. 784. 785. 786. 787. 788. 789. 790. 791. 792. 793. 794. 795. 796. 797. 798. 799. 800. 801. 802. 803. 804. 805. 806. 807. 808. 809. 810. 811. 812. 813. 814. 815. 816. 817. 818. 819. 820. 821. 822. 823. 824. 825. 826. 827. 828. 829. 830. 831. 832. 833. 834. 835. 836. 837. 838. 839. 840. 841. 842. 843. 844. 845. 846. 847. 848. 849. 850. 851. 852. 853. 854. 855. 856. 857. 858. 859. 860. 861. 862. 863. 864. 865. 866. 867. 868. 869. 870. 871. 872. 873. 874. 875. 876. 877. 878. 879. 880. 881. 882. 883. 884. 885. 886. 887. 888. 889. 890. 891. 892. 893. 894. 895. 896. 897. 898. 899. 900. 901. 902. 903. 904. 905. 906. 907. 908. 909. 910. 911. 912. 913. 914. 915. 916. 917. 918. 919. 920. 921. 922. 923. 924. 925. 926. 927. 928. 929. 930. 931. 932. 933. 934. 935. 936. 937. 938. 939. 940. 941. 942. 943. 944. 945. 946. 947. 948. 949. 950. 951. 952. 953. 954. 955. 956. 957. 958. 959. 960. 961. 962. 963. 964. 965. Второй запрос ВСЕ строки: Код: 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. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512. 513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 547. 548. 549. 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563. 564. 565. 566. 567. 568. 569. 570. 571. 572. 573. 574. 575. 576. 577. 578. 579. 580. 581. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737. 738. 739. 740. 741. 742. 743. 744. 745. 746. 747. 748. 749. 750. 751. 752. 753. 754. 755. 756. 757. 758. 759. 760. 761. 762. 763. 764. 765. 766. 767. 768. 769. 770. 771. 772. 773. 774. 775. 776. 777. 778. 779. 780. 781. 782. 783. 784. Третий запрос ВСЕ строки, но иначе (через IN): Код: 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. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. 430. 431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455. 456. 457. 458. 459. 460. 461. 462. 463. 464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481. 482. 483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512. 513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 547. 548. 549. 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563. 564. 565. 566. 567. 568. 569. 570. 571. 572. 573. 574. 575. 576. 577. 578. 579. 580. 581. 582. 583. 584. 585. 586. 587. 588. 589. 590. 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737. 738. 739. 740. 741. 742. 743. 744. 745. 746. 747. 748. 749. 750. 751. 752. 753. 754. 755. 756. 757. 758. 759. 760. 761. 762. 763. 764. 765. 766. 767. 768. 769. 770. 771. 772. 773. 774. 775. 776. 777. 778. 779. 780. 781. 782. 783. 784. 785. И вывод db2set -all Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 15:29 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Victor Metelitsause-seПолучается, чтобы использовать MDC нам придется отказаться от уникальности первичного ключа и вместо (с1,с2,с3) использовать индекс по c1. На уровне БД я проблем не виду, а вот со стороны софта придется смотреть. Если я правильно понимаю то, что вы написали, то вы всё ещё не понимаете, что такое MDC. Вы правильно понимаете, пока я не потрогаю руками сам - не пойму. Читал ради интереса не более. Относительно NLJOIN честно скажу, всего проверял 2 вида запроса 1) big_tab.c1_id=small_tab.c1_id 2) big_tab.c1_id ib (select c1_id from small_tab) попытаться как то инача переписать запрос в голову не приходлило. 2 таблицы, что тут искать, хоть какая либо предварительная выборка была бы. Подумать переписать, подумаю, попробую, может по частям может, или как распаралелить. Может попробовать в явном виде задать для заданного запроса план использования индекса? Статистику недавно собирал, но может сторит пересмотреть профиль сбора статистики с распределением по колонкам и индексам учавствующим в соединении? А может DB2 не использует hash join по причине, что hash таблицы получаюся слишком большими? Что то я совсем запутался )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 16:00 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-seVictor Metelitsaпропущено... Если я правильно понимаю то, что вы написали, то вы всё ещё не понимаете, что такое MDC. Вы правильно понимаете, пока я не потрогаю руками сам - не пойму. Читал ради интереса не более. Ну там же на картинках так наглядно нарисовано. Смысл в MDC по колонке X - сгруппировать вместе данные с одинаковым значением X, они будут группироваться экстентами. Когда X оказывается уникальным, у вас на экстенте оказывается ровно одна запись. Эффект - дикое и безумное распухание таблицы. Относительно NLJOIN честно скажу, всего проверял 2 вида запроса 1) big_tab.c1_id=small_tab.c1_id 2) big_tab.c1_id ib (select c1_id from small_tab) попытаться как то инача переписать запрос в голову не приходлило. 2 таблицы, что тут искать, хоть какая либо предварительная выборка была бы. Подумать переписать, подумаю, попробую, может по частям может, или как распаралелить. Может попробовать в явном виде задать для заданного запроса план использования индекса? Статистику недавно собирал, но может сторит пересмотреть профиль сбора статистики с распределением по колонкам и индексам учавствующим в соединении? А может DB2 не использует hash join по причине, что hash таблицы получаюся слишком большими? Что то я совсем запутался )) NLJOIN или HASH JOIN выбирать - это, вообще-то, личное дело оптимизатора, хотя он может ошибиться. HASH JOIN, в принципе, работает без индексов (хотя он может воспользоваться индексом, "как таблицей"). Использование индекса "как индекса" влечёт за собой одноблочный доступ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 16:49 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-seА может DB2 не использует hash join по причине, что hash таблицы получаюся слишком большими? Что то я совсем запутался )) точно нет. он должен был взять маленькую таблицу/индекс, которая весит всего 116 мб, по ней в памяти построить хэш и фуллсканом читать большую, параллельно вычисляя хэш и выдавая заджоиненный результат на выход. ничего быстрее тут не выдумать, разве что индекс по тем трем полям, что нужны запросу. а сейчас у вас NL долбит одноблочным чтением, не удивительно что это часы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 19:11 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
use-se, HSJOIN не обязательно будет быстрее NLJOIN в этой ситуации - соединение по одном полю при наличии индекса в маленькой таблице по этому полю. Если хотите сравнить, увеличьте значительно SORTHEAP и используйте оптимизационный профиль для указания использования HSJOIN. Можете даже пока не запуская запрос посмотреть на цену запроса такого плана и сравнить его с текущим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 20:45 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Yo.!точно нет. он должен был взять маленькую таблицу/индекс, которая весит всего 116 мб, по ней в памяти построить хэш и фуллсканом читать большую, параллельно вычисляя хэш и выдавая заджоиненный результат на выход. ничего быстрее тут не выдумать, разве что индекс по тем трем полям, что нужны запросу. а сейчас у вас NL долбит одноблочным чтением, не удивительно что это часы. Про одноблочное чтение - это откуда взято? В плане - табличное сканирование большой (внешней) таблицы. Метод доступа - sequential prefetch - это чтение экстентами (большими блоками). Какой здесь смысл здесь таблицу из одного уникального проиндексированного поля засовывать в память, вычислять хэш для каждого уникального поля, чтобы потом по нему получать доступ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 21:00 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Там два запроса и два плана. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 22:08 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Даже три. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 22:09 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#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. Ведущая таблица SMALL_TAB. Для каждого C1_ID происходит поиск BIG_TAB_PK, накапливаются и сортируются RID'ы (до 512-штук), затем происходит PREFETCH из BIG_TAB. Как я помню, оно кластеризовано и потому это имеет смысл. А для поиска в индексе PREFETCH'а нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 22:20 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#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. Ведущая таблица BIG_TAB (а если на ней сделать MDC по C1_ID, то есть надежда, что она станет ведомой). Она префетчится, как и следовало ожидать. Для SMALL_TAB используется index only access. PREFETCH: (Type of Prefetch) NONE. Абстрактно хеш джойн кажется более выгодным. То ли таблица не влезла, то ли что ещё. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 22:27 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Mark BarinsteinПро одноблочное чтение - это откуда взято? В плане - табличное сканирование большой (внешней) таблицы. Метод доступа - sequential prefetch - это чтение экстентами (большими блоками). я так понимаю в плане 2, на каждую запись большой таблицы идет IXSCAN: (Index Scan) с PREFETCH: NONE. сканирование реально один блок читает, т.е. тот самый долбеж. разве нет ? Mark BarinsteinКакой здесь смысл здесь таблицу из одного уникального проиндексированного поля засовывать в память, вычислять хэш для каждого уникального поля, чтобы потом по нему получать доступ? не так. в оракле из pk маленькой таблицы построился бы хеш в памяти, потом пошел бы фуллскан большой. по мере чтения большой создавался бы хеш по pk и сравнивался с хеш-таблицой в памяти. если ключ не найдет в баню, если найден, в результирующий курсор нужные поля. таким образом он мог бы хоть петабайты большой таблицы читать и получить результат за адекватное время. думаю с 347 гб таблицы реально минут за 20 справиться по такой схеме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 22:37 |
|
||
|
Есть ли ограничения на максимальную скорость выборки данных из одного табличного пространс
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 22:39 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=39327401&tid=1600519]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 173ms |

| 0 / 0 |
