Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Автоматизация перестройки БД под АСА 9 / 25 сообщений из 62, страница 1 из 3
29.01.2005, 17:51
    #32890850
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Есть проблема: при долгой работе сервера размер БД растет. Даже при очистке устаревших данных. Характер хранимых у нас данных таков, что через некоторое время эксплуатации системы количество записей выходит примерно на постоянную цифру - разную для каждого клиента. Старые данные удаляются/новые добавляются. Однако - размер базы растет постоянно!!! При стартовом объеме БД примерно в 25-30 мб за 4-5 месяцев она выросла до 700 (!!!) мегабайт! Помогает reload базы - из старой с созданием новой. Объем уменьшился на порядоук... Однако вручную таким заниматься не очень хочется... Может кто-то смог автоматизировать этот процесс???
Или есть какие-то советы по решению сложившейся проблемы??
...
Рейтинг: 0 / 0
29.01.2005, 18:12
    #32890860
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Vadim RomanenkoЕсть проблема: при долгой работе сервера размер БД растет. Даже при очистке устаревших данных. Характер хранимых у нас данных таков, что через некоторое время эксплуатации системы количество записей выходит примерно на постоянную цифру - разную для каждого клиента. Старые данные удаляются/новые добавляются. Однако - размер базы растет постоянно!!! При стартовом объеме БД примерно в 25-30 мб за 4-5 месяцев она выросла до 700 (!!!) мегабайт! Помогает reload базы - из старой с созданием новой. Объем уменьшился на порядоук... Однако вручную таким заниматься не очень хочется... Может кто-то смог автоматизировать этот процесс???
Или есть какие-то советы по решению сложившейся проблемы??
Скорее всего трабла в том, что при удалении данных получается сильная дефрагментация таблиц - страницы остаются полупустые, а если данные заливаются через LOAD TABLE или вставляются большими транзакциями, скорее всего ASA впихивает их на новые страницы для повышения скорости вставки. Попробуйте после удаления делать REORGANIZE TABLE, это дефрагментирует таблицы и освободит пустые страницы, а далее уже вставка записей и пойдет по этим пустым страницам.
...
Рейтинг: 0 / 0
29.01.2005, 18:13
    #32890861
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Посмотрите еще кстати в Central, насколько сильно таблицы дефрагментируются.
...
Рейтинг: 0 / 0
31.01.2005, 14:19
    #32892449
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
А как посмотреть в Централе фрагментацию?? Это какой-то параметр, или есть графическая утилита?

В последнее время вообще появилась непонятная проблема: нам привезли базу на испытания. Мы ее подняли. После попыток поанализировать данные централом (не помню уже куда ткнул) появилась ошибка об IO error. После переподнятия база доступна. Однако после того, как опускаешь сервер, она не хочет переписываться!! Что происходит??
...
Рейтинг: 0 / 0
31.01.2005, 14:34
    #32892512
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Vadim RomanenkoА как посмотреть в Централе фрагментацию?? Это какой-то параметр, или есть графическая утилита?
Можно посмотреть в Central вкладочку "Table Page Usage", если щелкнуть на саму БД и к ней никто, кроме Central на данный момент не подключен. Как посмотреть из ISQL, читайте в BOL:
BOL
Код: plaintext
1.
2.
ASA SQL User's Guide 
  Monitoring and Improving Performance 
    Fragmentation


Vadim Romanenko
В последнее время вообще появилась непонятная проблема: нам привезли базу на испытания. Мы ее подняли. После попыток поанализировать данные централом (не помню уже куда ткнул) появилась ошибка об IO error. После переподнятия база доступна. Однако после того, как опускаешь сервер, она не хочет переписываться!! Что происходит??
Думаю все это означает, что неплохо бы запустить скан-диск и поискать плохие сектора. Дело скорее всего не в ASA, а жестком диске и файловой системе.
...
Рейтинг: 0 / 0
14.02.2005, 16:08
    #32914627
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
ASCRUSПопробуйте после удаления делать REORGANIZE TABLE, это дефрагментирует таблицы и освободит пустые страницы, а далее уже вставка записей и пойдет по этим пустым страницам.

А кто пользовался REORGANIZE TABLE??
Такая ситуация: есть постоянно открытая сессия, которая вначале выполнила select из некоторой таблицы - пусть она называется indval. Есть желание эту таблицу отREORGANIZE'ить. Однако при выполнении команды
REORGANIZE TABLE indval;
происходит зависание процесса, выполнившего эту команду. Есть предположение, что все происходит из-за блокирования таблицы в результате select. Так ли это? Как с этим бороться?
...
Рейтинг: 0 / 0
14.02.2005, 17:40
    #32914919
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Vadim RomanenkoТакая ситуация: есть постоянно открытая сессия, которая вначале выполнила select из некоторой таблицы - пусть она называется indval. Есть желание эту таблицу отREORGANIZE'ить. Однако при выполнении команды
REORGANIZE TABLE indval;
происходит зависание процесса, выполнившего эту команду. Есть предположение, что все происходит из-за блокирования таблицы в результате select. Так ли это? Как с этим бороться?
Ну вообще то желательно после выполнения SELECT и полного получения курсора делать COMMIT. Это снимет SHARED блокировку с таблицы и позволит выполнять над ней DML команды и REORGANIZE TABLE.
...
Рейтинг: 0 / 0
15.02.2005, 10:02
    #32915682
michael_
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
ASCRUSСкорее всего трабла в том, что при удалении данных получается сильная дефрагментация таблиц - страницы остаются полупустые, а если данные заливаются через LOAD TABLE или вставляются большими транзакциями, скорее всего ASA впихивает их на новые страницы для повышения скорости вставки. Попробуйте после удаления делать REORGANIZE TABLE, это дефрагментирует таблицы и освободит пустые страницы, а далее уже вставка записей и пойдет по этим пустым страницам.
Эта проблема - одна из неприятных особенностей ASA. Может я ошибаюсь, но дело не сколько в сильной дефрагментации, сколько в плохом повторном использовании освободившихся страниц. Слищком уж сильно разрасрастается база. И дело не в LOAD и репликации, у нас и при обычных INSERT по одной записи тоже самое происходит. В MS SQL при том же стиле работы с нашим приложением и при тех же запросах такого не происходит. Максимум сжатия там 10-50%, а тут можно и 5-10 раз базу ужать. Е если не ужимать, то дальше будет расти. На ASA 6-8 было именно так, судя по заявлению автора топика, и на ASA9 тоже самое, жаль.

Хорошо хоть, что в ASA9 unload/reload работает раз в 10-20 быстрее, чем в ASA6-7. И этим стало можно пользоваться.

А REORGANIZE TABLE - не очень удобно, она естетвенно, требует монопольный доступ к таблице и увеличивает размер БД (надо же ей где-то данные промежуточные держать), легче всех выгнать и сделать unload/reload.
...
Рейтинг: 0 / 0
15.02.2005, 10:21
    #32915726
Александр Гoлдун
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
michael_ пишет:

> Эта проблема - одна из неприятных особенностей ASA. Может я ошибаюсь, но
> дело не сколько в сильной дефрагментации, сколько в плохом повторном
> использовании освободившихся страниц. Слищком уж сильно разрасрастается
> база. И дело не в LOAD и репликации, у нас и при обычных INSERT по одной
> записи тоже самое происходит. В MS SQL при том же стиле работы с нашим
> приложением и при тех же запросах такого не происходит. Максимум сжатия
> там 10-50%, а тут можно и 5-10 раз базу ужать.

Ну у меня максимум можно было ужать базы на 10-30% при помощи reload.
Что я делаю не так? Если единовременно вставить большой объем данных,
который потом удалить - тогда да, ужимается сильно. Но если не делать
reload, то это избыточное место повторно используется, что можно
проверить путем повторной вставки аналогичного объема данных.

Это все асбстрактные слова, пока не приведены номера версий, хотя бы
упрощенная структура БД, скрипты для "обычных INSERT" и статистика роста
размера.
Posted via ActualForum NNTP Server 1.1
...
Рейтинг: 0 / 0
15.02.2005, 10:46
    #32915800
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Александр Гoлдун
michael_ пишет:

> Эта проблема - одна из неприятных особенностей ASA. Может я ошибаюсь, но
> дело не сколько в сильной дефрагментации, сколько в плохом повторном
> использовании освободившихся страниц. Слищком уж сильно разрасрастается
> база. И дело не в LOAD и репликации, у нас и при обычных INSERT по одной
> записи тоже самое происходит. В MS SQL при том же стиле работы с нашим
> приложением и при тех же запросах такого не происходит. Максимум сжатия
> там 10-50%, а тут можно и 5-10 раз базу ужать.

Ну у меня максимум можно было ужать базы на 10-30% при помощи reload.
Что я делаю не так? Если единовременно вставить большой объем данных,
который потом удалить - тогда да, ужимается сильно. Но если не делать
reload, то это избыточное место повторно используется, что можно
проверить путем повторной вставки аналогичного объема данных.

Это все асбстрактные слова, пока не приведены номера версий, хотя бы
упрощенная структура БД, скрипты для "обычных INSERT" и статистика роста
размера.
Posted via ActualForum NNTP Server 1.1
Присоединяюсь. У меня на ASA9 на некоторые таблицы в результате перерасчетов удаляются тысячи записей и вставляются столько же новых - и никакого прироста файла БД просто не наблюдается. С операциями UPDATE база вырастает на кол-во страниц, над которыми идет UPDATE, далее после успешного прохождения транзакции эти страницы становятся пустыми и используются в дальнейших операциях. Плюс я специально, в тестах над большими таблицами, удалял прямо кусками записи и потом добавлял вновь - таблица не разбухала, не набирала новых страниц и не фрагментировалась. Сами разработчики ASA вообще рекомендуют сразу увеличивать пространство файла БД на некоторую величину, чтобы быстрее происходила работа с БД. Лично я считаю основной причиной сильной дефрагментации таблиц и расбухания файла БД могуть быть постоянные UPDATE на большое кол-во записей над полями, у которых типы с плавающей длиной и неоптимально выставленной PCTFREE.
...
Рейтинг: 0 / 0
15.02.2005, 12:03
    #32916036
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Александр Гoлдун
Это все асбстрактные слова, пока не приведены номера версий, хотя бы
упрощенная структура БД, скрипты для "обычных INSERT" и статистика роста
размера.


Вот наша таблица:

create table INDVAL
(
NCHANNEL_ID numeric(30,0) not null,
VACPER varchar(1) not null,
VVALTYPE varchar(1) not null,
NVALUE numeric(30,6) not null,
VQUALITY varchar(1) not null,
DDATE timestamp not null,
DINPUT timestamp not null
);

/*==============================================================*/
/* Index: RELATION_100_FK */
/*==============================================================*/
create index RELATION_100_FK on INDVAL (
NCHANNEL_ID ASC
);

alter table INDVAL
add foreign key FK_INDVAL_RELATION__CHANNEL (NCHANNEL_ID)
references CHANNEL (NCHANNEL_ID)
on update restrict
on delete restrict;

она практически единственная изменяющаяся в нашей бд (хранит показания счетчиков электричества). Есть процедура очистки, выполняется раз в день. Удаляет примерно 5-10 тыс. записей в день по признаку устаревания (дата показания). Средний объем - 300-400 тыс. записей.
Primary key отсутствует для экономии места на диске.
Вставка записей идет потоком простыми insert'ами.
За время эксплуатации с сентября по январь выросла до 750 мегабайт вместе с лог-файлом. Без него занимала примерно 450 мегабайт. В конце-концов отказалась выполняться на Cyrix 800/256 мб (такое паршивое семейство процессоров из-за одноплатного исполнения - все на борту кроме памяти). Точнее база конечно запускалась, но инициализация приложения происходила за 20 минут, в то время как после unload-reload эта же самая процедура занимала несколько _секунд_. После unload-reload стала занимать 61 мегабайт. По-моему совввввершенно конкретные цифры.
...
Рейтинг: 0 / 0
15.02.2005, 12:06
    #32916052
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
ASCRUS Vadim RomanenkoТакая ситуация: есть постоянно открытая сессия, которая вначале выполнила select из некоторой таблицы - пусть она называется indval. Есть желание эту таблицу отREORGANIZE'ить. Однако при выполнении команды
REORGANIZE TABLE indval;
происходит зависание процесса, выполнившего эту команду. Есть предположение, что все происходит из-за блокирования таблицы в результате select. Так ли это? Как с этим бороться?
Ну вообще то желательно после выполнения SELECT и полного получения курсора делать COMMIT. Это снимет SHARED блокировку с таблицы и позволит выполнять над ней DML команды и REORGANIZE TABLE.

Честно говоря с такой глупостью мы встретились впервые. На АСА. Мы тоже дошли до этого решения. Но как-то не очень мне кажется хорошо, когда простой select лочит таблицу так, что с ней ничего нельзя сделать... Непонятны мотивы.
...
Рейтинг: 0 / 0
15.02.2005, 12:26
    #32916133
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Vadim RomanenkoЧестно говоря с такой глупостью мы встретились впервые. На АСА. Мы тоже дошли до этого решения. Но как-то не очень мне кажется хорошо, когда простой select лочит таблицу так, что с ней ничего нельзя сделать... Непонятны мотивы.
Гм, абсолютно понятные мотивы - пока на SELECT клиент не закрывает курсор, на таблицах висит SHARED-TABLE блокировка на запрет выполнения на них DML операторов. Собственно говоря DDL операторам она никак не мешается, зато гарантирует, что пока клиент не решил, что больше он с таблиц, участвующих в запросе ничего не хочет, их метаструктура не изменится.
...
Рейтинг: 0 / 0
15.02.2005, 12:35
    #32916160
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Vadim Romanenkoона практически единственная изменяющаяся в нашей бд (хранит показания счетчиков электричества). Есть процедура очистки, выполняется раз в день. Удаляет примерно 5-10 тыс. записей в день по признаку устаревания (дата показания). Средний объем - 300-400 тыс. записей.
Primary key отсутствует для экономии места на диске.
Вставка записей идет потоком простыми insert'ами.
За время эксплуатации с сентября по январь выросла до 750 мегабайт вместе с лог-файлом. Без него занимала примерно 450 мегабайт. В конце-концов отказалась выполняться на Cyrix 800/256 мб (такое паршивое семейство процессоров из-за одноплатного исполнения - все на борту кроме памяти). Точнее база конечно запускалась, но инициализация приложения происходила за 20 минут, в то время как после unload-reload эта же самая процедура занимала несколько _секунд_. После unload-reload стала занимать 61 мегабайт. По-моему совввввершенно конкретные цифры.
Ну вы даете - сэкономили на PK, зато сделали FK с неявным индексом, да еще явный индекс на то же поле :) Тормоза обеспечены, заодно думается и разбухание БД уже видится довольно ясно. Не может ASA без PK или UK/UI жить, любит она их, так как она "порядочная" РСУБД :) Я бы рекомендовал Вам вставить в таблицу PK и обязательно убить индекс по CHANNEL. Или вместо его убивания наоборот убить FK и на AFTER ON INSERT, UPDATE FOR EACH STATEMENT триггерах реализовать проверку ссылочной целостности, раз уж у Вас такие обьемы вставляются и удаляются. Каскады так же можно реализовать на триггерах в таблице CHANNEL.

P.S. В общем еще раз очередное подтверждение, что от граммотного проектирования БД зависят все параметры ее функционирования - от скорости, до разбухания :)
...
Рейтинг: 0 / 0
15.02.2005, 13:31
    #32916335
michael_
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Отстутсвие PK - это плохо.

Но! Причем здесь отсутсвие PK и разбухание БД, если после удаление данных страницы памяти освободились и уже не принадлежат таблице? Не вижу логики.
...
Рейтинг: 0 / 0
15.02.2005, 14:00
    #32916450
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
michael_Отстутсвие PK - это плохо.

Но! Причем здесь отсутсвие PK и разбухание БД, если после удаление данных страницы памяти освободились и уже не принадлежат таблице? Не вижу логики.
При вставке записей ASA будет стараться их вставлять по PK или кластерному индексу. Соотвествующе если удаление соотносится с этим же порядком (я так понимаю в приведенном примере записи в основном будут вставлять и удаляться по CHANNEL) - то даже приблизительная физическая сортировка записей в таблице будет давать преимущества в виде меньшей дефрагментированности таблицы и при удалении будут чаще освобождаться страницы до состояния пустых. Из чего я делаю вывод, что самый большой повод разрастаться БД - это допускать сильную дефрагментацию таблиц.

P.S. Кстати REORGANIZE TABLE по моему нельзя делать на таблицы, у которых нет PK.
...
Рейтинг: 0 / 0
15.02.2005, 14:16
    #32916516
michael_
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
ASCRUS michael_Отстутсвие PK - это плохо.

Но! Причем здесь отсутсвие PK и разбухание БД, если после удаление данных страницы памяти освободились и уже не принадлежат таблице? Не вижу логики.
При вставке записей ASA будет стараться их вставлять по PK или кластерному индексу. Соотвествующе если удаление соотносится с этим же порядком (я так понимаю в приведенном примере записи в основном будут вставлять и удаляться по CHANNEL) - то даже приблизительная физическая сортировка записей в таблице будет давать преимущества в виде меньшей дефрагментированности таблицы и при удалении будут чаще освобождаться страницы до состояния пустых. Из чего я делаю вывод, что самый большой повод разрастаться БД - это допускать сильную дефрагментацию таблиц.


Согласен с приведенными аргументами, но они не согласуются с приведенной статистикой. Не должна она была так быстро расти.

А у нас всегда есть PK на каждую таблицу и pctfree стоит по умолчанию (то есть вообще не указана при создании таблицы) и картина весьма похожа, только все развивается не так стремительно.

Повторяю - на MS такого не наблюдается. То есть дело не в рялиционной теории.
...
Рейтинг: 0 / 0
15.02.2005, 16:37
    #32916975
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
ASCRUS
Ну вы даете - сэкономили на PK, зато сделали FK с неявным индексом, да еще явный индекс на то же поле :)

м-м-м-м... а где там два индекса на одно и то же поле?? насколько я понимаю, тот индекс генерится автоматически при создании FK. Мы его вручную не добавляли... Скрипт сгенерил мне PowerDesigner. Я честно говоря его даже не смотрел... Да и в студии в списке индексов нет индекса по полю NCHANNEL_ID
...
Рейтинг: 0 / 0
15.02.2005, 16:41
    #32916987
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
/*==============================================================*/
/* Index: RELATION_100_FK */
/*==============================================================*/
create index RELATION_100_FK on INDVAL (
NCHANNEL_ID ASC
);

alter table INDVAL
add foreign key FK_INDVAL_RELATION__CHANNEL (NCHANNEL_ID)
references CHANNEL (NCHANNEL_ID)
on update restrict
on delete restrict;
Ну тогда это PD "намутил" :)
...
Рейтинг: 0 / 0
15.02.2005, 16:49
    #32917014
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
ASCRUS[quot michael_]Отстутсвие PK - это плохо.

Но! Причем здесь отсутсвие PK и разбухание БД, если после удаление данных страницы памяти освободились и уже не принадлежат таблице? Не вижу логики.
При вставке записей ASA будет стараться их вставлять по PK или кластерному индексу. Соотвествующе если удаление соотносится с этим же порядком (я так понимаю в приведенном примере записи в основном будут вставлять и удаляться по CHANNEL) - то даже приблизительная физическая сортировка записей в таблице будет давать преимущества в виде меньшей дефрагментированности таблицы и при удалении будут чаще освобождаться страницы до состояния пустых. Из чего я делаю вывод, что самый большой повод разрастаться БД - это допускать сильную дефрагментацию таблиц.


ASCRUS
P.S. Кстати REORGANIZE TABLE по моему нельзя делать на таблицы, у которых нет PK.
Таки да, таки нельзя. Но для экспериментов на стенде добавили индекс - и обнаружили проблемы с блокированием.
Скажу все же, почему мне это кажется дикостью. Потому, что приличные СУБД предоставляют средства для дефрагментации он-лайн. При подключенных пользователях.
По поводу блокирования select'ом таблицы... Например в Оракле по-моему такой глупости нету, как-то решается этот вопрос. Там даже есть такая возможность - зафиксировать состояние БД для сессии. Точнее, данных в БД. (ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE) И чего бы кто ни вставлял в базу, человек, выполнивший эту команду, увидит лишь данные, которые были на момент сериализации сессии. А тут... Обычный селект открывает транзакцию что-ли раз ее нужно закрывать? Коммитом???
...
Рейтинг: 0 / 0
15.02.2005, 17:54
    #32917026
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
ASCRUS
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
/*==============================================================*/
/* Index: RELATION_100_FK */
/*==============================================================*/
create index RELATION_100_FK on INDVAL (
NCHANNEL_ID ASC
);

alter table INDVAL
add foreign key FK_INDVAL_RELATION__CHANNEL (NCHANNEL_ID)
references CHANNEL (NCHANNEL_ID)
on update restrict
on delete restrict;
Ну тогда это PD "намутил" :)
дело в том, что в списке индексов в студии тоже не видно такого индекса как RELATION_100_FK. Не может так быть, что он просто автоматический??

хотя... я только что сделал unload базы - там почему-то этот индекс (RELATION_100_FK) отсутствует... Мда.
...
Рейтинг: 0 / 0
15.02.2005, 18:04
    #32917043
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Vadim Romanenko
хотя... я только что сделал unload базы - там почему-то этот индекс (RELATION_100_FK) отсутствует... Мда.
Извиняюсь за дезинформацию. Индекса в базе таки нет. Видать появился глюк в PD при переходе с одной версии на другую. На физическом уровне этот индекс отсутствует... Так что вариант с двумя индексами на одно поле просьба больше не рассматривать...
...
Рейтинг: 0 / 0
15.02.2005, 18:31
    #32917096
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Vadim RomanenkoТаки да, таки нельзя. Но для экспериментов на стенде добавили индекс - и обнаружили проблемы с блокированием.
Скажу все же, почему мне это кажется дикостью. Потому, что приличные СУБД предоставляют средства для дефрагментации он-лайн. При подключенных пользователях.
По поводу блокирования select'ом таблицы... Например в Оракле по-моему такой глупости нету, как-то решается этот вопрос. Там даже есть такая возможность - зафиксировать состояние БД для сессии. Точнее, данных в БД. (ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE) И чего бы кто ни вставлял в базу, человек, выполнивший эту команду, увидит лишь данные, которые были на момент сериализации сессии. А тут... Обычный селект открывает транзакцию что-ли раз ее нужно закрывать? Коммитом???
Гм - с чего бы это нам сравнивать версионник Oracle и блокировочник ASA ? Разные архитектуры, разные возможности. А SHARED TABLE блокировка обьясняется просто - у ASA не поддерживаются в транзакциях команды DDL, в отличие от Oracle. Поэтому и блокировка на изменение метаструктуры вешается. Поэтому и проектировать логику работы с БД в ASA нужно согласно ее архитектурным особенностям и COMMIT после SELECT ставить. И транзакции длинными не делать. И тогда окажется, что и REORGANIZE в онлайн прекрасно работает, постепенно дефрагментируя данные, танцуя между транзакциями сессий :)
...
Рейтинг: 0 / 0
15.02.2005, 19:15
    #32917200
Александр Гoлдун
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
Vadim Romanenko
create table INDVAL

ASA 9.0.2.2545 (кстати, ты не упомянул свою версию)
Сделал подобную таблицу, кроме того сделал такую же по структуре INDVAL2

В INDVAL2 залил 128 тыс записей.

Дальше выполняю много раз:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
INSERT INTO INDVAL
SELECT * FROM INDVAL2

commit

DELETE FROM INDVAL

commit

checkpoint

После второго выполнения размер файла db зафиксировался и больше не вырастал ни на байт .
Transaction log, естественно, растет ОЧЕНЬ БЫСТРО, ибо:
BOL
You can control how fast the transaction log file grows by ensuring that all your tables have compact primary keys. If you carry out updates or deletes on tables that do not have a primary key or a unique index not allowing NULL, the entire contents of the affected rows are entered in the transaction log. If a primary key is defined, the database server needs to store only the primary key column values to uniquely identify a row. If the table contains many columns or wide columns, the transaction log pages fill up much faster if no primary key is defined. In addition to taking up disk space, this extra writing of data affects performance.


т.е. при удалении при наличии PK в лог попадет
Код: plaintext
1.
DELETE FROM INDVAL WHERE id=NNN
, а при отсутствии
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
DELETE FROM INDVAL WHERE 
 NCHANNEL_ID = ....
 AND VACPER ='..'
 AND VVALTYPE ='..'
 AND NVALUE =...
 AND VQUALITY ='..'
 AND DDATE ='..'
 AND DINPUT='..'
Разница чувствуется?
...
Рейтинг: 0 / 0
15.02.2005, 19:21
    #32917210
Vadim Romanenko
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Автоматизация перестройки БД под АСА 9
ASCRUSГм - с чего бы это нам сравнивать версионник Oracle и блокировочник ASA ? Разные архитектуры, разные возможности.
ну да, согласен, я немножко неудачное сравнение привел :) ни к чему конечно. Разные вещи...

Но по поводу селекта... Дело в том, что у нас есть служебная сессия, которая все время висит в бэкграунде и иногда вычитывает некоторые данные из базы. Вот эта сессия и оказалась блокирующей для REORGANIZE TABLE. Никто никаких транзакций не открывал особо. Обычный селект. Просто я никогда не встречал такого тупичка, что после селекта нужно закрывать транзакцию. Как-то специфично уж очень... Это надо как-то пересмотреть наше приложение... Которое впринципе не привязано к конкретной БД. Считается, что если переписать пару процедур - то все будет работать на любом сервере... А ради селектов в АСА грубить такое... Ладно, поглядим. Но все равно это выглядит странно.
...
Рейтинг: 0 / 0
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / Автоматизация перестройки БД под АСА 9 / 25 сообщений из 62, страница 1 из 3
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]