Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
22.03.2006, 12:13
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
База 570Гб, в централе хотел посмотреть статистику использования страниц, в итоге сервер ушел в какой-то долгий цикл и ему не хватило 9 часов. Ждать больше не представлялось возможным, поэтому убил, т.к. в процессе подсчета этой статистики сервер не отзывается. Неужели прочитать с диска 570 гигов это так долго? Как бы мне узнать много ли пустых страниц в базе? (видимо никак) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 12:28
|
|||
|---|---|---|---|
|
|||
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
iLLer пишет: > База 570Гб, Ух ты! Пол-терабайта? И как оно живет и на чем? > Неужели прочитать с диска 570 гигов это так долго? У меня дома скорочть чтения с винта около 30 мб/с. Чисто тупо чтение такого объема в идеальном случае будет делаться 5 с половиной часов. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 12:46
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
да нормально живет, каши не просит. Фактически хранилище. Машина обычный пень 4, 512 М памяти, винтов 3 вроде, сцеплены в один логический 1Тб с хвостом. База работает замечательно, только терзает душу риск повреждения одного "левого байтика", после чего база не запустится. Вообще мне на самом деле не очень нравится такой подход, хотя получается самодостаточная система со встроенным ВЕБ интерфейсом. Да, что-то про скорость я и не подумал, у нас 50 метров в сек, получается что порядка 3 часов - предел мечтаний. А вот если б в АСА завели где-нить уже готовый статистический срез, то было бы гораздо удобней. Ведь запрос в виндах на объем свободного пространства на винте выполняется мгновенно, потому как такая инфа уже вычислена заранее. А делать последовательный скан базы, да еще с блокированием страниц и коннектов - это выглядит уж совсем как не продуманность. Может разработчики АСА решили, что это мало кому потребуется... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 12:53
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
А не пробовали через DBINFO.EXE или ХП sa_table_page_usage() получить статистику ? Может быстрее выйдет. P.S. Кстати насчет хранения - если БД не работает круглосуточно, то может быть имеет смысл периодически по ночам запускать EVENT, который через ХП будет коллекционировать информацию в собственную таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 13:12
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
Дык, централ как раз и запускает sa_table_page_usage(), я хотел это дело протестить и на ночь запустил, утром же сервер в цикле что-то читал, и конца и края не видно было. Думаю не судьба на такой базе узнать свободные страницы, по крайней мере если рабочую базу куда-нить не оттащить и там подождать этот процесс. Но полтеррабайта никуда не оттащишь!)))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 14:06
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
Надо бы им в форум заявить, пускай это дело оптимизируют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 14:20
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
Кстати - нужно опцию "DEDICATED_TASK" попробовать, она как раз переводит сессию в эклюзивный режим доступа к БД и вроде как заявлено, что она как раз предназначена для таких длительных операций, как сбор статистики или же массовое обновление записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 14:34
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
У меня такое ощущени, что дедикэйтет таск как раз автомат включается при выполнении этой процедуры. Ибо если есть хоть один коннет к базе, то АСА ругается и говорит, что ему нужно чтоб никто не мешал. А уж когда начнет работать, то ни подключиться новой сессией, ни чего бы то ни было еще сделать нельзя, прямо монополизация получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 15:05
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
iLLerУ меня такое ощущени, что дедикэйтет таск как раз автомат включается при выполнении этой процедуры. Ибо если есть хоть один коннет к базе, то АСА ругается и говорит, что ему нужно чтоб никто не мешал. А уж когда начнет работать, то ни подключиться новой сессией, ни чего бы то ни было еще сделать нельзя, прямо монополизация получается. Вот уж не думаю. Сейчас взял БД размером 2,6 гб, где десятки миллионов записей по таблицам размазаны. Без дедиката процедура статистики таблиц отработала 318 сек. С включенной опцией 115 сек, то есть разница в 2 раза. Оба раза сервер БД останавливал, чтобы с нуля начиналась работа. P.S. Кстати надо будет проапдейтить миллиончики записей, посмотреть, не ускорит ли эта опция массовое обновление. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 15:55
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
Надо будет попробывать с опцией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.03.2006, 15:56
|
|||
|---|---|---|---|
TablePageUsage на большой БД (ASA9.02.3221) |
|||
|
#18+
Проверил эту опцию на обновление табличке с 10300000 записей. Результаты обновления: без опции: UPDATE = 341 сек, COMMIT = 39 сек, скушано CACHE=640 mb с опцией: UPDATE = 237 сек, COMMIT = 34 сек. скушано CACHE=580mb сервер перегружался между тестами, естественно для ускорения апдейта я выставил опции RECOVER_TIME, COOPERATIVE_COMMIT_TIMEOUT и использовал LOCK TABLE EXCLUSIVE. Разница как видно в 100 секунд, что неплохо и кэша меньше кушается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/search_topic.php?author=vfedorov&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 647ms |
| total: | 799ms |

| 0 / 0 |
