|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#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 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Извините, мне показалась Ваша мысль не закончена? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2003, 19:38 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Лично мне отделение индексов от таблиц и использование разных буферных пулов совсем не кажется таким уж очевидно хорошим делом. Например, пусть у нас два дисковых массива - на одном данные, на другом индексы. При сканировании таблицы будет простаивать один массив, при index only access - другой. Что касается разных буферных пулов для разных типов таблиц, то если у вас мелкие таблицы используются часто, а крупные (с фуллсканом) - редко, то, по идее, мелкие таблицы не должны вымываться из пула? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2003, 14:05 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Ну главное - это позволяет снизить I/O, а не то, что мы все про это думаем :)) Но бездумное использование buferpool может навредить - факт, и IBM это даже где-то в доке указало, точно помню это видел в доке по тюнингу IBM LDAP Вот не вижу, что может пострадать, в случае разнесения данных и индексов. Может поясните? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2003, 16:07 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Нашел, кстати, интересные рекомендации, официальная докумениация, концепсия, раздел настройки производительности, так вот там есть советы по поводу нескольких контейнеров, и как это сообразуеться с разными задачами, и что использование нескольких контейнеров резко усиливает паралеллизм выполненя, и всё такое прочее, и ничего от том, как и что это ухудшает. Но IBM - сторона заинтересованная :) Самая беспристрастная аудитория - админы :) Таки может кто скажет, как разнесение данных и индексов таблиц и применение множественных контейнеров влияют на производительность в хужшую сторону? Про лучшую и так понятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2003, 16:39 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Буферные пулы: надо ж учитывать не только состав данных, но и нагрузку. Частые сканирования больших таблиц - выгодна одна конфигурация, но если редкие - то другая. Разнесение данных и индексов. Аналогично, надо учитывать нагрузку. В чем выгода raid'а для чтения? В одновременном доступе к нескольким дискам. Надо полагать, что чем больше дисков мы задействуем, тем больше общая скорость обмена. Таким образом, выделив отдельные диски под индекс и имея главным образом index only access, мы выделим под это меньшее количество дисков, чем если держать данные и индексы вместе. Здесь тоже предполагаются определенные условия, которые необязательно выполняются. Короче, настоящий ответ может дать только тестирование с реальными данными и реальной нагрузкой. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2003, 14:24 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
Опускаю bufferpool как не вызывающий сомнения. А вот с дисками - позвольте не согласиться. Первое - бкзо всякого raid можно иметь tablespace с множетсвенными контейнерами, каждый из которых отдельный диск, и при соответсвующем кол-ве NUM_IOSERVERS доступ ко всем контейнерам/дискам будет одновременной (при наличии соотв. ресурсов, таких как BUS/CPU - cамо собой) Второе - с учётом первого пункта, что мешает для индексного tablespace иметь столько контейнеров/дисков, сколько надо, организовав доступ паралельно? Третье - имея отдельный tablespace для индексов на raid опять же что может помешать иметь столько дисков, сколько надо? Четвертое - при совместном хранении данных и дисков мы стопудово получаем конкуренцию за доступ к хранилищу, которую мы не можем контролировать - ну не можем мы задать условия для хранения данных на отдельных дисках raid от индексов, и если часть данных и индексов попадает на один диск - метания головок обеспечены. И никакие raid не смогут обеспечить такую же паралельность как в случае раздельного хранения и множественных контейнеров. ПОмоему, от задач это слабо зависит. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2003, 14:37 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
RAID 0 на N дисках и N контейнеров на N дисках - я думаю, что логически это примерно одно и то же. "мешает для индексного tablespace иметь столько контейнеров/дисков, сколько надо" - а сколько надо? Я так подозреваю, что кашу маслом не испортишь (к сожалению, нет возможности заниматься тестированием так, как мне бы хотелось). "если часть данных и индексов попадает на один диск - метания головок обеспечены" - как будто они и так не обеспечены. Базы то (как правило) многопользовательские. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2003, 13:00 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
1) Ну да 2) Столько - сколько паралеллизма в I/O хочеться 3) Совсем не согласен.Многопользовательность здесь ни совсем к месту. Каждый элемент I/O транзакции может быть или последовательным - если данные и индексы на одном диске, или паралельными - если на разных. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.11.2003, 15:14 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
2. То есть деньгами и техническими возможностями сервера вы совсем не лимитированы? Круто. 3. Пусть N клиентов запустили одновременно N запросов, производящих фуллсканы на M разных таблицах. Вы утверждаете, что все эти запросы будут выстроены в очередь и выполнены последовательно, то есть K-й в очереди клиент будет ждать, когда выполнятся K-1 чужих запросов, прежде чем начнетсы выполнение его запроса? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2003, 11:00 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
2) - ну диски ведь стоят не так уж и много, тем более что не нужны супер ёмкие. Подключить дополнительно D1000 тоже не проблема, когда будет некуда - заказать следующую I/O board. Ну чтобы забить все возможные I/O board на сервере - это очень отдаленная перспектива, во всяком случае, это будет означать смену сервера, и опять таки будет планироваться заранее. 3) Нет, не я утверждаю, а документация IBM, и не это она утверждает, а всего лишь то, что для получения максимального паралелизма и I/O лучше всего разнести данные и инжексы, и так далее по тексту. Я не склонен не согласиться с этим. И в дополнение - разнесение данных и индексов повидимому не имеет никакого отношения к полному сканированию таблицы, так что я не совсем понял, к чему вы клоните. Но вот выполнение INSERT/UPDATE определенно выиграют от того, что данные будут вставляться/обновляться на одном контроллере, а индексы 0 на другом. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2003, 16:21 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
2. Ну значит, для кого как. В нашей конторе мы сильно лимитированы. Поэтому-то я и проверить толком ничего не могу. А тесты могут длиться неделями и месяцами, чтобы проверить все аспекты. 3. При делении имеющейся пачки дисков на две - диски для индексов и диски для данных - наверняка одна будет недогружена (в зависимости от данных, индексов и нагрузки). Для того, чтобы мысль была яснее, я привел предельный пример - "N клиентов запустили одновременно N запросов, производящих фуллсканы на M разных таблицах". Пачка (то есть массив) дисков с индексами простаивает. А ведь чем больше дисков используется, тем больший можно ожидать суммарный трансфер? (Реально у меня обратная картина - многие запросы index only). Теперь вернемся к "N клиентов запустили одновременно N запросов, производящих фуллсканы на M разных таблицах". Индексная пачка дисков простаивает (или не простаивает, другие K клиентов делают что-то с index only access). Будут ли метаться головки дисков с данными? Думаю, что будут все равно. Такая же картина с модификациями данных - выгода разделения индексов и данных мне совсем не очевидна. В этом вопросе я могу поверить только тестам. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2003, 10:43 |
|
Разбивка таблицы на разделы.
|
|||
---|---|---|---|
#18+
У меня картина обратная - множество запросов INSERT/UPDATE, валящих с огромной скоростью от разных клиентов, паралельно, и редкое выполнение SELECT - для менеджеров статистика. Результат при разнесении виден был не вооруженным взглядом - в пик тайм выросла общая пропускная способность в выполненных транзакциях, благо мне ждать не надо, легко пиковое время сэмулировать - остановить внесение данных в базу, дать им накопиться в очередях, и затем запустить сервис внесения - имеем полный нагруз. В результате полных сканирований таблиц, очевидно, выиграша в разделении не будет. Честно говоря, я такую ситуацию не могу себе представить. Хотя всё может быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2003, 14:34 |
|
|
start [/forum/topic.php?all=1&fid=43&tid=1606420]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 299ms |
total: | 456ms |
0 / 0 |