|
Спорный вопрос по Sybase
|
||
|---|---|---|
Участник
Откуда: Из ближайшего подмосковья.
Сообщения: 2 130 |
||
| 30.04.2003, 16:43 |
|
|
Период между сообщениями больше года.
|
|
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Привет всем. Вопрос такой. Ускоряет ли transaction log работу с базой или нет. У меня знакомые разработчики с пеной у рта убеждают, что этот самый лог чуть ли не в несколько раз ускоряет работу базы. Хотя, по логике вещей, дополнительные операции записи-чтения никогда не улучшали быстродействие. Так ли это ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2003, 15:08 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Простите, а как же Вы без него работать собрались? Как же Вы будете поддерживать транзакционную целостность? Правда ASA может работать без этого лога, но ТОЛЬКО в однопользовательском режиме, и без каких либо откатов транзакций. Т.к. все изменения СРАЗУ ЖЕ записываются в базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2003, 16:43 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Но ведь работаю же, и транзакции откатываются. Правда, работаю я на Sybase Anywhere 5.5.05, там, чтобы лог сам усекался, нужно опцию -m задать. Файл лога сейчас около 64 Кбайт, и не пухнет совсем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.04.2003, 17:01 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Не надо так пугать (путать) людей. Вопрос должен звучать так: Ускоряет ли "Truncate the transaction log when a checkpoint is done." работу с базой или нет ( параметр в строке запуска -m)? PS. Тщательнее надо формулировать свои мысли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.05.2003, 09:41 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
не ускоряет, а замедляет(лог то надо обрезать) а вообще без разницы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2003, 08:34 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
И всё же вопрос знатокам ASA. Предположим, стоит база без репликаций. С ней работают 3...20 юзеров. Обычная система финансового характера - заводятся клиенты, счета, выполняются операции, раскладываются на проводки. Формируются отчеты - как простенькие типа выписки по счету, так и (иногда) тяжелые - типа оборотов по всем счетам за месяц с разного рода групповыми извращениями. То есть ничего особенного, все как у всех. Так вот - нужен ли такой базе transaction log? Ускорит он работу или замедлит? Чем еще может быть полезен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 17:23 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
по хелпу - с логом быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 17:49 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
MastiffОбычная система финансового характера - заводятся клиенты, счета, выполняются операции, раскладываются на проводки. Формируются отчеты - как простенькие типа выписки по счету, так и (иногда) тяжелые - типа оборотов по всем счетам за месяц с разного рода групповыми извращениями. То есть ничего особенного, все как у всех. Так вот - нужен ли такой базе transaction log? Да, нужен. Она же не Readonly. Ускорит он работу или замедлит? Да, ускорит. Чем еще может быть полезен? Повышением надёжности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 17:53 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Александр Спелицин Правда ASA может работать без этого лога, но ТОЛЬКО в однопользовательском режиме, и без каких либо откатов транзакций. Не верю (с) Станиславский Читайте доки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 18:15 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Нет, он не ускоряет и не замедляет. Он делает работу с базой данных ВООБЩЕ ВОЗМОЖНОЙ . Без лога - это не база данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 18:26 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Изивините, немного запоздал с ответом. Прочитал-подумал - а как же он ускоряет -то ? Давайте подробнее, раз уж раскололись . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 18:28 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Я фигею, дорогая редакция! Сколько людей - столько мнений: 1. Замедляет 2. Ускоряет 3. Без него только однопользовательская работа 4. Без него невозможен коммит 5. Без него работать вообще невозможно и это не база данных 6. Без него база read only Что еще будет? Можно просто почитать доки, либо поэкспериментировать либо самому догадаться: 5. Monitoring and Improving Performance Top performance tips Always use a transaction log You might think that Adaptive Server Anywhere would run faster without a transaction log because it would have to maintain less information on disk. Yet, the opposite is actually true. Not only does a transaction log provide a large amount of protection, it can dramatically improve performance. Operating without a transaction log, Adaptive Server Anywhere must perform a checkpoint at the end of every transaction. Writing these changes consumes considerable resources. With a transaction log, however, Adaptive Server Anywhere need only write notes detailing the changes as they occur. It can choose to write the new database pages all at once, at the most efficient time. Checkpoints make sure information enters the database file, and that it is consistent and up to date. ------- Конец цитаты ------------- Переводить, надеюсь, не надо? В двух словах, без лога: а) Делает чекпоинты на каждый commit, что отъедает ресурсы и, соответсвенно, тормозит работу. б) Отсутствует информация для репликации или инкрементального бэкапа (накатывания) или же просто для разбора полетов. в) Значительно уменьшается устойчивость к сбоям Для пользователя же фунциональных отличий в работе нет. Есть и многопользовательская работа и транзакционная целостность. P.S. объяснять, что такое чекпоинт, бэкап и сбои или не надо? ) -- http://talk.ru/forum/talk.ru.accounting.development ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 19:33 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Только сейчас заметил - тему то подняли полутаролетней давности : 30 апр 03 P.S. И погоняло у автора особенно приятное... P.P.S. И на сайте у них в портфолио гордо светится "Специализированный SQL сервер для систем с повышенными требованиями к быстродействию, надежности и защищенности" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.11.2004, 19:50 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Всё оно, конечно, так, и доки процитированные зачитаны до дыр в мониторе. Проблема вот в чем - база в течение месяца справляется "одной левой", с трёхкратным запасом по скорости. Но процедура закрытия месяца отрабатывает около 3-4 часов. Практически вся логика процедуры сидит на сервере в хранимках. Почти все тормоза - из-за чтения/записи больших объёмов информации. (я не прошу сейчас помочь с оптимизацией структуры базы или алгоритмов, это была бы другая тема) А вот к чему я все это рассказывал: Если ОТКЛЮЧИТЬ transaction log перед выполнением этой мега-процедуры, она отрабатывает БЫСТРЕЕ. Процента на 3...10 в разных тестах, но стабильно БЫСТРЕЕ, зараза! Как она могла так с нами поступить? ;-)) Правда, лог лежит на том же диске, что и база. Но всё равно же и в этом варианте "должно быть" быстрее, или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2004, 14:46 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
MastiffВсё оно, конечно, так, и доки процитированные зачитаны до дыр в мониторе. Проблема вот в чем - база в течение месяца справляется "одной левой", с трёхкратным запасом по скорости. Но процедура закрытия месяца отрабатывает около 3-4 часов. Практически вся логика процедуры сидит на сервере в хранимках. Почти все тормоза - из-за чтения/записи больших объёмов информации. (я не прошу сейчас помочь с оптимизацией структуры базы или алгоритмов, это была бы другая тема) А вот к чему я все это рассказывал: Если ОТКЛЮЧИТЬ transaction log перед выполнением этой мега-процедуры, она отрабатывает БЫСТРЕЕ. Процента на 3...10 в разных тестах, но стабильно БЫСТРЕЕ, зараза! Как она могла так с нами поступить? ;-)) Правда, лог лежит на том же диске, что и база. Но всё равно же и в этом варианте "должно быть" быстрее, или нет? В лог идет физическая запись на жесткие диски. Вывод - естественно он замедляет работу. Однако лог - это надежность и дополнительные функциональные возможности (инкрементный бакуп, репликация, накат лога и т.д.). Вывод - ради надежности и таких возможностней вполне обоснованно можно чуть пожертвовать скоростью. Смешно из за 3-10% ускорения так серьезно задаваться выбором между скоростью и надежностью. Конечно можно просто в RAM создать виртуальный диск и крутить БД на нем или включить кэширование IO операционной системой - производительность вырастет на глазах. Однако наверное будет правильнее задуматься вот об этом: автор(я не прошу сейчас помочь с оптимизацией структуры базы или алгоритмов, это была бы другая тема) и не валить свои проблемы со скоростью на архитектуру СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2004, 15:21 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Хм. А разве я говорил, что хочу отрезать лог навсегда? Я хочу увеличить скорость, ИСПОЛЬЗУЯ лог - как это написано в доке, которую процитировал уважаемый Александр Голдун. Быть может, кто-то сумел так заколдовать лог, чтобы он скорость работы базы увеличил? Или же такой уровень магии только техническим писателям Sybase,Inc. доступен? ;-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 14:51 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
MastiffХм. А разве я говорил, что хочу отрезать лог навсегда? Я хочу увеличить скорость, ИСПОЛЬЗУЯ лог - как это написано в доке, которую процитировал уважаемый Александр Голдун. Быть может, кто-то сумел так заколдовать лог, чтобы он скорость работы базы увеличил? Или же такой уровень магии только техническим писателям Sybase,Inc. доступен? ;-)) По моему из приведенной ссылки Александром видно, что без лога работа СУБД замедлится, где за норматив скорости берется работа БД с логом. Как Вы из этого вывели, что с помощью лога можно увеличивать скорость работы СУБД ума не приложу. Насчет колдовства над БД и логом запросто - увеличьте доступную под кэш память, поставьте более скоростные процессоры и винты, разнесите DBSpace, лог и temporary files на разные устройства, оптимизируйте нагрузки, запросы и структуру БД - эти меры гарантированно приведут к увеличению скорости работы. А чтобы из за некой "волшебной" опции вдруг все стало работать быстрее - такого не бывает. Другой способ - если Вам не особо важны надежность и поддержка транзакционной модели, то увеличить скорость можно просто перейдя на MySql. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.11.2004, 15:30 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Цетирую дословно из ASA SQL User's Guide Глава "Советы по достижению наивысшей производительности". Может возникнуть впечатление, что без журнала транзакций быстродействие ASA повыситься из-за необходимости поддерживать меньше кол-во информации на диске. На самом деле журнал транзакций не только в значительной степени обеспечивает защиту, но и реально повышает производительность. При работе без жернала ASA приходиться устанавливать контрольные точки по завершению каждой транзакции. Запись этих изменений требуе значительных ресурсов. При наличии журнала ASA записывает только примечания , подробно описывающие изменения по мере их возникновения. И т.д. и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2004, 11:17 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
20.1 Журнал контрольной точки Файл базы данных WATCOM SQL составлен из страниц. Прежде, чем страница модифицируется (сделается грязной), всегда делается ко- пия оригинала. Скопированные страницы - журнал контрольной точки. Грязные страницы не записываются немедленно на диск. Для повыше- ния эффективности, они кэшируются в памяти и записываются на диск, когда кэш полон или сервер не имеет никаких ожидающих зап- росов. Контрольная точка - отметка, в которой все грязные страни- цы записываются на диск. Если все грязные страницы записываются на диск, журнал контрольной точки удаляется. Контрольная точка может происходить по нескольким причинам: 1. Транзакция выводит команду CHECKPOINT. 2. Сервер очень долго не активизировался, чтобы записывать все грязные страницы. 3. Процессор базы данных работает без журнала транзакций и транзакция фиксируется. 4. Процессор базы данных завершил работу. 5. В DOS, однопользовательская программа ждет ввод с клавиату- ры, и процессор базы данных имеет достаточное количество времени, чтобы записать все грязные страницы и выполнить CHECKPOINT. 6. Количество времени с последней контрольной точки превысила опцию базу данных CHECKPOINT_TIME. 7. Вычисляемое время, чтобы сделать операцию восстановления, превышает опцию базы данных RECOVERY_TIME. Приоритет записи грязной страницы на диск будет увеличиваться пропорционально времени и количеству работы, возрастающим с пос- ледней контрольной точки. Это будет важно, когда процессор базы данных не имеет достаточное количество времени простоя, чтобы за- писать грязные страницы. Две опции базы данных, упомянутые выше, позволяют вам управлять частотой контрольных точек. CHECKPOINT_TIME будет управлять желательным максимумом времени между контрольными точками, и RECOVERY_TIME будет управлять жела- тельным максимумом временем для восстановления в случае отказа системы. Оба времени определяются в минутах (см."SET OPTION" стр.344). 20.2 Журнал отката Поскольку изменения делаются с содержимым таблиц, журнал отката хранится с целью отмены изменений. Он используется для обработки запросов ROLLBACK и для восстановления при отказе системы. Имеет- ся свой журнал отката для каждой транзакции. Когда транзакция закончена, журнал отката удаляется. 20.3 Журнал транзакций Все действия процессора базы данных сохраняются в журнале тран- закций в порядке их выполнения. Вставки, модификации, удаления, фиксирование, откаты и изменения структуры базы данных - все ре- гистрируется. На журнал транзакций часто ссылаются как на файл журнала. Журнал транзакций необязателен. Когда вы выполняете WATCOM SQL без журнала транзакций, контрольная точка будет выполнена всякий раз, когда любая транзакция фиксируется (commit). Контрольная точка необ- ходима, чтобы гарантировать, что все зафиксированные транзакции записываются на диск. Запись грязных страницы может потреблять время, так что вы должны работать с журналом транзакций для повы- шения эффективности, а также защиты против отказа носителя и раз- рушения базы данных. Журнал транзакций не хранится в главном файле базы данных. Имя файла журнала транзакций может устанавливаться, когда база дан- ных инициализируется (с DBINIT), или в любой другой раз (с DBLOG), когда процессор базы данных не запущен. Чтобы защититься против отказа носителя, журнал транзакций не должен записываться на одно устройство с файлом базы данных. Некоторые машины с дву- мя или более жесткими дисками имеют только один физический дис- ковод с несколькими логическими дисками или разделами. Если вы требуете защиту против отказа носителя, удостоверьтесь, что вы имеете машину с двумя запоминающими устройствами или используете запоминающее устройство на сетевом файл-сервере. Обратите внима- ние, что по умолчанию, журнал транзакций помещается на то же са- мое устройство и в тот же самый каталог, что и база данных, а это не защищает от отказа носителя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2004, 13:11 |
|
||
|
Спорный вопрос по Sybase
|
|||
|---|---|---|---|
|
#18+
Вы судя по всему документацию цитируете. Глаз за одну несуразицу зацепился: old_joyЕсли вы требуете защиту против отказа носителя, удостоверьтесь, что вы имеете машину с двумя запоминающими устройствами или используете запоминающее устройство на сетевом файл-сервере. Хранить лог на сетевом диске это имхо извращение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2004, 09:09 |
|
||
|
|
start [/forum/topic.php?fid=55&msg=32780613&tid=2014046]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
158ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 16ms |
| total: | 273ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
