|
|
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Пожалуйста, подскажите, названия каких-нибудь технологий архивации данных БД Oracle (12c), которые просто внедрить, и не трудно сопровождать? Которые можно использовать для архивации данных, при переполнении табличных пространств. Мне для гуглинга. Не откажусь от дельных и внятных рекомендаций. Просьба без хейтинга, я прикладник. Придумываю работу для страдальцев-ДБА ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 17:22 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
У меня вот сейчас аналогичная задача, начал с компрессирования, там, где это осмыслено. Table compress, key compress. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 17:27 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfio, Compress для начала ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 17:27 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
как я понял из описания compression, нужно перезаливать данные из несжатой таблицы/пространства в сжатую? если так, то это довольно дорогой вариант. Вариант с alter compression ..move кажется еще дороже.. какие еще бывают технологии? Подскажите, пожалуйста, сворачивание на ленту части таблицы возможно? если да, то как? (имею ввиду не перенос из большой в пустую лишних данных, а именно ее отрезание какой-нибудь архивирующей технологией) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 17:46 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
к тому же интернет говорит, что загрузка данных в сжатую таблицу замедляется почти в 2 раза. Этот вариант не подходит. Есть еще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 17:50 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfio, процесс скользящего окна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 18:05 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfio, вы б для начала своих страдальцев-ДБА спросили, что ли а то пойдете потом лесом со своими нагугленными нововведениями ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 18:05 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
DВА, Я вот своего не спросил. Ворчит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 18:07 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
AmKad, секционирование с удалением/переносом в другую базу на говнодисках через exchange partition и transportable tablespace ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 18:09 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
Партиционирование - это да, а вот к переносу данных во вновь созданную говнобазу, в которой будут продублированы сущности с точно такой же структурой, к решению проблем с доступа к этим же говноданным при необходимости, я пока не готов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 18:41 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
AmKad, но это проще, чем из бэкапа их тащить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 18:58 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
нарезатель, И? Ты предлагаешь перепартиционирование. Считаешь, что перекомпрессия принципиально сложнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 19:58 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfioкак я понял из описания compression, нужно перезаливать данные из несжатой таблицы/пространства в сжатую? если так, то это довольно дорогой вариант. Вариант с alter compression ..move кажется еще дороже..А тебе самому не кажется абсурдной твоя хотелка, если ты хочешь сжать при этом, чтоб данные остались как есть? wolfioк тому же интернет говорит, что загрузка данных в сжатую таблицу замедляется почти в 2 разаПеречитай интернет еще разок. Вкратце, если таблица сжата, то вновь вставленные данные в conventional insert будут несжатыми, а в direct path insert сжатыми. Скорость может проседать в очень специфических случаях для conventional insert и не в два раза. Иными словами, может получится так что данные в некоторых блоках сегмента сжаты, а в некоторых нет. Крайне прискорбно когда такие "специалисты" еще имеют наглость для кого-то придумывать работу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 20:01 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopВкратце, если таблица сжата, то вновь вставленные данные в conventional insert будут несжатыми, а в direct path insert сжатыми. В доке заявлено, что compress for oltp (он же for all operations) в отличие, например, от basic, работает для всех DML операций. В частности, для conventional insert он работает. Тест Код: plsql 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. Исходный код для желающих поиграться Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2017, 23:44 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfioкак я понял из описания compression, нужно перезаливать данные из несжатой таблицы/пространства в сжатую? если так, то это довольно дорогой вариант. Вариант с alter compression ..move кажется еще дороже..Move избавляет тебя от необходимости делать drop/create/rename (со всеми вытекающими проблемами доступа к данным) + grant + disable/enable fk + comment. У move конечно тоже есть побочный эффект - инвалидация индексов (для приложения это тоже может пройти с определенными проблемами), а значит появляется необходимость их перестроения. Но раз ты встал на православный путь компрессии, то весомую часть из-них так или иначе имеет смысл rebuild-ить c кляузой compress. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 00:12 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
AmKadтак или иначе имеет смысл rebuild-ить c кляузой compressпо моему скромному опыту для oltp-систем чаще выгоднее включать компрессию только для архивных секций (или делать сплит периодически с компрессией), но индексы не сжимать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 04:18 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
AmKadимеет смысл rebuild-ить c кляузой compress.я б для начала прошелся по индексам analyze-м (Analyze Index Validate Structure), посмотрел чего оно покажет (select * from index_stats, только нужно помнить, что там храниться всегда одна строка для последнего проанализированного индекса), а уж после бы принимал решение о включении компрессии по тому или иному индексу.... А то может оказаться, что овчинка и выделки-то не стоит... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 04:41 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, простите, что задел ваши чувства гордого администратора. я сам не в восторге, что роюсь в предметной области, в которой ничего не знаю и работать не планирую.. тем не менее проблеме роста базы уже 2 года минуло, а местные "специлисты-ДБА" считают, что это не их работа. компрессия не подходит потому, скорость записи и чтения данных не должна измениться. Задача вообще стоит так - минимизировать рост табличных пространств с индексами, соответственно. При этом хотелось бы просто выдергивать архивные данные, и убирать куданибудь в бэкап, очищая забитую в экстентах память. Кстати, если, допустим, таблица весит 1тб, индекс ну скажем 200гб, то удалив 500гб из таблицы индекс уменьшится сам? или его нужно пересоздавать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 09:15 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfio, Партицировать и перемещать старые партиции. Глобальные индексы перестраивать (rebuild). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 09:29 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
fortnet, мне сказали, что партицирование не подходит как технология, потому что занимает слишком много времени создание партиций с переносом данных. хотя хз конечно, 1 раз перетерпеть можно было бы, но это я так думаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 09:40 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfio, любая "технология архивирования" для своей первоначальной "инициализации" потребует слишком много времени и ресурсов. потому как данные всё равно придется перемещать, иначе, как уже было замечено, как ты без ворошения данных сделаешь так, чтобы они стали занимать меньше места? ну и поверь уже, компрессия не так уж и сильно скажется на производительности. Скорее всего, её влияния в этом аспекте ты даже и не заметишь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 09:46 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfiofortnet, мне сказали, что партицирование не подходит как технология, потому что занимает слишком много времени создание партиций с переносом данных. хотя хз конечно, 1 раз перетерпеть можно было бы, но это я так думаю. Нет сомнений в том, что они уже имеют большой опыт в этом. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 10:27 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
Добрый Э - Эх ну и поверь уже, компрессия не так уж и сильно скажется на производительности. Скорее всего, её влияния в этом аспекте ты даже и не заметишь... enq: TX - allocate ITL entry легко могут приехать, если не позаботиться об этом заранее. К тому же багов полно ещё на компрессии. Например, ALERT Bug 21923026 Corruption during Recovery after upgrading to 12c for Compressed Tables (Doc ID 2058461.1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 12:44 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfio... сворачивание на ленту части таблицы возможно? А вы забумывались про: Какова процедура доступа к данным, которые вы сбрасываете на ленту? Сможете восстановить хотя бы 5-ти летние данные? (старые ленты не всегда читаются) А если у вас не будет совместимого устройства для чтения старых лент? (личный опыт) А если у вас не будет БД Oracle? (например оптимизация и переход на P...sql и т.п.) А если у вас не будет своих спецов, а только аутсорс и на удаленке без физического доступа? и так далее. Если для вас затраты на хранилище в бОльшем приоритете, чем данные, тогда такие "данные" можно удалять. А если данные важнее, тогда и компрессия не страшна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 15:12 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfiodbms_photoshop, простите, что задел ваши чувства гордого администратора. я сам не в восторге, что роюсь в предметной области, в которой ничего не знаю и работать не планирую.. тем не менее проблеме роста базы уже 2 года минуло, а местные "специлисты-ДБА" считают, что это не их работа. Совершенно верно. Это не их работа, а архитектора системы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 15:16 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
AmKadDВА, Я вот своего не спросил. Ворчит. то что он ворчит, вобщем-то наплевать и забыть, а вот то, что нагугленное решение может в принципе не подходить для данной системы - это уже другой вопрос ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 15:18 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfiofortnet, мне сказали, что партицирование не подходит как технология, потому что занимает слишком много времени создание партиций с переносом данных. хотя хз конечно, 1 раз перетерпеть можно было бы, но это я так думаю. складывается впечатление, что вы уже и сами не знаете чего хотите. Если у вас непродуманная архитектура бд, то практически любое ее изминение будет болезненым. Если вы больше не хочете раздувать свой hard-массив, то выбирайте партиционирование с замещением старых партиций новыми, темболее что от версии к версии этот механизм совершенствуется, например в версии 12c глобальные индексы уже можно обслуживать аснхронно, а партиции каскадно. Также незабывайте контролировать размеры: temporary space, логов, бэкапов и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 15:36 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
AmKadВ доке заявлено, что compress for oltp (он же for all operations) в отличие, например, от basic, работает для всех DML операций. В частности, для conventional insert он работает. Всё верно. Я подразумевал basic. Если в твоем тесте 1) поменять тип на basic 2) увеличить число строк до 1e6 3) добавить --+ append то результаты будут такими Код: plaintext 1. 2. 3. Код: plaintext 1. 2. 3. Время примерно одинаковое. Сжатие для этих специфических данных в 10 раз. При conventional никакого эффекта не будет ни по времени ни по сжатию. Если вернуться к compress for oltp, то целесообразность подобного компромисса весьма сомнительна 1. Компрессия как правило применяется к архивным данным, а не активным 2. Прирост нагрузки на CPU таким может быть ощутимым 3. При удалениях и последующих вставках ожидаемого сжатия может не быть. Имеет множество случаев когда работает "весьма странно". В свое время была у меня подборочка, когда анализировали разные типы. Можно нагуглить много интересного начиная от блога Льюиса и заканчивая этим форумом move compress for oltp . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 16:30 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfioк тому же интернет говорит, что загрузка данных в сжатую таблицу замедляется почти в 2 раза. Этот вариант не подходит. Есть еще? так сперва обычно партицируют исторические данные и потом старые партиции сжимают. на вставку в текущую партицию никак это не влияет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 16:32 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfiodbms_photoshop, простите, что задел ваши чувства гордого администратора. я сам не в восторге, что роюсь в предметной области, в которой ничего не знаю и работать не планирую.. тем не менее проблеме роста базы уже 2 года минуло, а местные "специлисты-ДБА" считают, что это не их работа. компрессия не подходит потому, скорость записи и чтения данных не должна измениться. Задача вообще стоит так - минимизировать рост табличных пространств с индексами, соответственно. При этом хотелось бы просто выдергивать архивные данные, и убирать куданибудь в бэкап, очищая забитую в экстентах память. Кстати, если, допустим, таблица весит 1тб, индекс ну скажем 200гб, то удалив 500гб из таблицы индекс уменьшится сам? или его нужно пересоздавать?Я эникейщик, а не админ, не стоит извинений. Стоит только больше думать и читать перед тем как писать. Все твои суждения про целесообразность (или ее отсутствие) выглядят весьма нелепо из-за крайне низкого уровня знаний и соотвественно бестолковых выводов. Для того, чтоб минимизировать время простоя ты можешь рассмотреть dbms_redefinition, edition based redefinition или просто грамотное планирование действий в окне простоя системы. Касаемо скорости записи, как уже было сказано, при испольвании basic и секционирования ты добьешься и сжатия архивных данных (не это ли заголовок твоей темы) и неизменную скорость работы с активными данными. И самое главное, чтоб подумать и предложить что-то дельное не надо быть специалистом с 25 лет опыта Оракла, достаточно почитать доку, блоги, презентации + много экспериментов. Ты же просто предлагаешь какие-то инициативы имея крайне поверхностное понимание. И одно дело, если б ты просто определил цель, но ты же строишь нелепые концепции и пытаешься указывать другим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 16:44 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
Kumotoriwolfio... сворачивание на ленту части таблицы возможно? А вы забумывались про: Какова процедура доступа к данным, которые вы сбрасываете на ленту? Сможете восстановить хотя бы 5-ти летние данные? (старые ленты не всегда читаются) А если у вас не будет совместимого устройства для чтения старых лент? (личный опыт) А если у вас не будет БД Oracle? (например оптимизация и переход на P...sql и т.п.) А если у вас не будет своих спецов, а только аутсорс и на удаленке без физического доступа? и так далее. Если для вас затраты на хранилище в бОльшем приоритете, чем данные, тогда такие "данные" можно удалять. А если данные важнее, тогда и компрессия не страшна.Хорошая попытка блеснуть умом, только Код: plaintext 1. 2. Часто ты при разработке политики архивирования думаешь, что будет если в будущем не будет Оракл и своих спецов? Я надеюсь возможный ядерный взрыв тоже учитываешь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 16:50 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, немного offtop вчера вот только в райфе слушал недо_scna, он рассказывал про hadoop и сопутствующие технологии типа oracle big data lite, external tables над hdfs. вот думаю после переезда на 12 попробовать как раз вариант поиграться с вариантами, пока придумал такие: партицирование и compress данных старше 1 года на некоторых фактических таблицах. view+ insted of trigger над таблицей с данными за последний год+таблица с историческими данными без индексов ну и на крайний случай view+ insted of trigger над таблицей с данными за последний год+external tables над hdfs скорее всего конечно будет партицирование со сжатием. все таки намного проще реализуемо, но и другие варианты тоже продумываю, еще можешь подкинуть что-то на подумать? данные важны только за текущий год. скорость предыдуших годов не важна. горячие данные только текущий и предыдущий месяц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 17:05 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfiodbms_photoshop, простите, что задел ваши чувства гордого администратора. я сам не в восторге, что роюсь в предметной области, в которой ничего не знаю и работать не планирую.. тем не менее проблеме роста базы уже 2 года минуло, а местные "специлисты-ДБА" считают, что это не их работа. А вы на общественных началах, так сказать, пытаетесь решить задачу. Не стоит делать чужую работу. А вашим специалистам где бы не работать, лишь бы не работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 17:15 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
Vintdbms_photoshop, немного offtop вчера вот только в райфе слушал недо_scna, он рассказывал про hadoop и сопутствующие технологии типа oracle big data lite, external tables над hdfs. вот думаю после переезда на 12 попробовать как раз вариант поиграться с вариантами, пока придумал такие: партицирование и compress данных старше 1 года на некоторых фактических таблицах. view+ insted of trigger над таблицей с данными за последний год+таблица с историческими данными без индексов ну и на крайний случай view+ insted of trigger над таблицей с данными за последний год+external tables над hdfs скорее всего конечно будет партицирование со сжатием. все таки намного проще реализуемо, но и другие варианты тоже продумываю, еще можешь подкинуть что-то на подумать? данные важны только за текущий год. скорость предыдуших годов не важна. горячие данные только текущий и предыдущий месяц. Не очень понял зачем insted of trigger. Для хранилищ должны быть очень серьезные аргументы в пользу такого решения. Data Offload счас предлагают все кто не лень от Oracle и MSSQL и заканчивая специфическими приблудами типа Gluent Smart Connector от Подера. Я вижу смысл оффлоадить данные только если можно также оффлоадить не только примитивные фильтры и projection, но и такие операции как групировка и при этом данные нужны в более агрегированном виде чем они хранятся (ну или фильтры хорошо фильтруют данные). Иначе, по факту, only scanning + selection + projection will be offloaded, после чего здоровенная порция данных будет перекачана из hadoop кластера в Oracle для последующих соединений и прочего. Ясное дело, о выполнении оракловой специфики типа connect by на стороне hadoop и речи быть не может. По крайней мере на данном этапе развития технологий. Хотя работу аналитических функций в ближайшие годы, вероятно, может будет вынести. Они уже реализованы и в Oracle и в той же Impala, но проблема распределить работу. Для старта - я рекомендовал бы ознакомиться с презентацией Подера Connecting Hadoop and Oracle , потом углябляться в интересующие моменты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 18:10 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, ты бы не воспринимал все так в штыки.. форум вроде как для того и нужен, чтобы по теме общаться, разве нет? мне показалось, что лучше спросить опытных людей, чем читать доку. тем более, что я ограничен временем, а от меня, как от прикладника, не требуется реализация. Требовалась просто идея для обсуждения. изначально я и спросил ключи для гуглинга. в любом случае, сейчас вопрос уже не актуален. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 19:17 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
wolfioмне показалось, что лучше спросить опытных людей, чем читать докуДа, тебе показалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 19:29 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, По поводу Gluent можно еще здесь посмотреть: https://vimeo.com/196497024 на мой вкус чуть больше деталей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2017, 23:27 |
|
||
|
Архивирование данных
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, насчет ограничений sql это то понятно, как и насчет большого объема перекачки в некоторых случаях. просто обдумываю пока направления в которых копать. и смотрю документацию и презенташки. Про подера как раз позавчера слышал, скоро доберусь посмотреть) спасибо. drema201, Ну вот, а говорил, что на форуме бывает редко)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2017, 10:11 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1886345]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
155ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 439ms |

| 0 / 0 |
