|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
15.11.2004, 12:39
|
|||
|---|---|---|---|
Пару вопросов по ASA/ |
|||
|
#18+
В отличие от пятой АСА, в девятой есть такой мощный инструмент как dbspaces. Возникает естественное желание разнести нагруженные таблицы, индексы и временные таблицы по разным девайсам (желательно разнесенные по разным дискам). В связи с этим есть пару соображений: 1. производительность БД заметно проседает от т.н. фрагментации таблиц БД внутри самого файла БД. Кажется логичным разнести большие нагруженные на вствку таблицы по разным дбспэйсам, что должно снизить время между необходимыми релоадами БД, ну и поднять скорость. 2. Индексы нагруженных таблиц вынесть в девайс отличный от девайса самой таблицы (опять таки снижение фрагментации и увеличение скорости). 3. Временные таблицы в скриптах также выносить в отдельный специальный девайс (create .. temporary table ... on tmpdbspace) и желательно вместе с временной директорией (ASTEMP). Т.к. я сейчас АСА9 ковыряю в тестовом режиме, то хочется узнать мнение по поводу, насколько предложенные методы "правильные" и насколько хорошо этот механизм дбспэйсов реализован вообще. Например, можно ли поднять БД, если один из неглавных дбспэйсов будет поврежден или отсутствовать. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.11.2004, 13:25
|
|||
|---|---|---|---|
|
|||
Пару вопросов по ASA/ |
|||
|
#18+
Ggg_oldВ отличие от пятой АСА, в девятой есть такой мощный инструмент как dbspaces. А разве в 5-й нельзя было разнести таблицы и индексы по разным файлам? По-моему в 5.5 это уже было Ggg_old Возникает естественное желание разнести нагруженные таблицы, индексы и временные таблицы по разным девайсам (желательно разнесенные по разным дискам). В связи с этим есть пару соображений: 1. производительность БД заметно проседает от т.н. фрагментации таблиц БД внутри самого файла БД. Кажется логичным разнести большие нагруженные на вствку таблицы по разным дбспэйсам, что должно снизить время между необходимыми релоадами БД, ну и поднять скорость. Необязательно. Начиная с 8-й версии есть возможность переупорядочить таблицу (см REORGANIZE TABLE) и использовать кластерные индексы Ggg_old 3. Временные таблицы в скриптах также выносить в отдельный специальный девайс (create .. temporary table ... on tmpdbspace) и желательно вместе с временной директорией (ASTEMP). А разве временные таблицы пишутся физически в файлы БД? Ggg_old Т.к. я сейчас АСА9 ковыряю в тестовом режиме, то хочется узнать мнение по поводу, насколько предложенные методы "правильные" Все хорошо в меру. Главное не переусердствовать в создании проблем на свою 5-ю точку и четко понимать, что делаешь и зачем Ggg_old Например, можно ли поднять БД, если один из неглавных дбспэйсов будет поврежден или отсутствовать. Бэкап, бэкап и еще раз бэкап. Когда чинил базы у клиентов, у которых не был настроен регулярный бэкап, принципиально поднимал стоимость работ. В назидание, так сказать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.11.2004, 13:47
|
|||
|---|---|---|---|
Пару вопросов по ASA/ |
|||
|
#18+
А разве в 5-й нельзя было разнести таблицы и индексы по разным файлам? По-моему в 5.5 это уже было C АСА 5.05 последний раз работал пару лет назад и такой возможности там кажется небыло. Необязательно. Начиная с 8-й версии есть возможность переупорядочить таблицу (см REORGANIZE TABLE) и использовать кластерные индексы Попробую, но в ASE лучше все равно было лучше делать релоад. А разве временные таблицы пишутся физически в файлы БД? Это как раз интересно. В доке по этому вопросу было четко написано, что во временных файлах в директории %ASTEMP%, АСА хранит т.н. worktables, т.е. предварительные сортировки и.т.п. Про временные таблицы не сказано ни слова. В разделе про врменные таблицы так же не написано, что они создаются во временных файлах. В конструкции CREATE LOCAL TEMPORARY TABLE можно указывать DBSPACE, где будет она создаваться, т.е. логично думать, что времянки создаются в самой БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.11.2004, 13:58
|
|||
|---|---|---|---|
Пару вопросов по ASA/ |
|||
|
#18+
В 5.5 это было (факт), в старших версиях дали возможность раскидывать индексы по dbspace. Гимор начинался именно при повреждении или отсутствии оного на момент старта базы. База стартовала, но прикрутить обратно восстановленный или отсутствовавший на момент старта сегмент в пятерке не удавалось в 99 % случаев (только пересоздание). Как вывод из этого - было рассматривать сегменты как единое целое базы (чем они и являются). Ну а разброс наиболее часто используемых данных (индексов) на более быстрые девайсы думаю обсуждению не подлежит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.11.2004, 14:09
|
|||
|---|---|---|---|
Пару вопросов по ASA/ |
|||
|
#18+
Ggg_old Это как раз интересно. В доке по этому вопросу было четко написано, что во временных файлах в директории %ASTEMP%, АСА хранит т.н. worktables, т.е. предварительные сортировки и.т.п. Про временные таблицы не сказано ни слова. В разделе про врменные таблицы так же не написано, что они создаются во временных файлах. В конструкции CREATE LOCAL TEMPORARY TABLE можно указывать DBSPACE, где будет она создаваться, т.е. логично думать, что времянки создаются в самой БД. BOL - CREATE TABLE STATEMENT: авторIN clause The IN clause specifies the dbspace in which the table is to be created. If the table is a GLOBAL TEMPORARY table, the IN clause is ignored. Конструкции CREATE LOCAL TEMPORARY TABLE вообще нет, локальные временные таблицы создаются через DECLARE LOCAL TEMPORARY TABLE и в этом операторе нет ни слова об упоминании IN. Еще BOL: авторTemporary tables are stored in the temporary file. Like any other dbspace, pages from the temporary file can be cached. Operations on temporary tables are never written to the transaction log. Так что Ваши выводы неправильные, читайте внимательней RTFM :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.11.2004, 14:56
|
|||
|---|---|---|---|
Пару вопросов по ASA/ |
|||
|
#18+
2 Ascrus: По отношению ко мне верна пословица, - поспешишь, людей насмешишь. Глаза мне "темнило" ASEшно прошлое. Но вот есть одна непонятка, которую я что-то не могу понять. Как вы привели цитату из доки: Temporary tables are stored in the temporary file. Like any other dbspace, pages from the temporary file can be cached. Operations on temporary tables are never written to the transaction log. В разделе доки по DECLARE LOCAL TEMPORARY TABLE написано: The NOT TRANSACTIONAL clause provides performance improvements in some circumstances because operations on non-transactional temporary tables do not cause entries to be made in the rollback log. Т.е с одной стороны операции с временной таблицей в лог не попадают, а с другой стороны есть опция NOT TRANSACTIONAL. Я что-то недопонимаю, поясните пожалуйста этот момент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
15.11.2004, 16:02
|
|||
|---|---|---|---|
Пару вопросов по ASA/ |
|||
|
#18+
Судя по всему имеется ввиду, что времянки не попадают в сегменты лог-файла, которые отвечают за ведение истории выполнений команд. Однако в сегменты, отвечающие за rollback естественно пишутся, иначе как бы можно было произвести откат транзакции для них. С учетом того, что для отката после сбоя ASA использует именно лог-файл, можно предположить, что "rollback log" храниться именно в лог-файле. В итоге получается, что во время транзакции ведется запись как минимум в несколько сегментов лог-файла и раз действия над временными таблицами не логируются, значит они работают быстрее, чем обычные таблицы. Так же получается NOT TRANSACTIONAL времянки в итоге и в rollback-log ничего не пишут, то есть фактически при работе с ними к лог-файлу вообще не идет никаких операций записи, что опять же здорово повышает скорость работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=55&tablet=1&tid=2014092]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
167ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 270ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
