ASCRUSМалость дополню высказывания White Owl:

White OwlВо первых, индекс на временную таблицу создавать обычно не стоит
Согласен - тут PK на времянку хватит выше крыши. Еще стоит помнить, что создание индекса даже на времянку имеет AUTOCOMMIT эффект, так что с этим можно наколоться, если к примеру создание индекса на времянку идет в контексте вызова из триггера. Кстати в догонку - создание индекса на любую таблицу с использованием вычисляемого столбца или функции приводит в довесок еще и к CHECKPOINT в БД.

White OwlВо вторых, если в своей Contract таблице ты сделаешь primary key (contractnumber) то индекс на него создастся автоматически и дополнительный индекс только замедлит работу.
Тут кстати еще желательно всегда подумать, с какой стороны будет предпочтительнее использовать индекс. По поведению ASA могу сказать, что чаще всего серверу будет предпочтительнее вести TABLE SCAN по обновляемой таблице и осуществлять поиск по индексу на присоединенной, так как читая страницы обновляемой страницы при нахождении записей в присоединенной можно будет сразу же обновлять на нужные значения и попутно вешать на присоединенную блокировки при требовании соотвествующего уровня изоляции (где самым удачным будет наличие подходящего в присоединенной таблице уникального индекса, на который и можно будет без каких либо затрат развешивать блокировки).

White OwlВ третьих, оптимизатор вещь достаточно умная. Ему можно доверять.
И главное понимать

White OwlА в четвертых и в главных если ты обновляешь таблицу Contract и не указал where в update, то естественно ты обновляешь все записи этой таблицы и использовать индекс на Contract бессмысленно. Вот индексы и не подхватываются.
Для White Owl: А WHERE и не нужно - есть же соединение на ON в JOIN - это и есть тот самый WHERE ;)

White OwlА вообще, я бы подобный запрос написал так:

Угу, можно попробовать - оптимизатор уведет в плане поиск по индексу присоединенной таблицы в подзапрос из главного запроса и частенько для больших обьемов данных поиск в подзапросе по индексу работает быстрее, чем стандартное соединение по индексу через NESTED LOOPS JOIN. Но нужно все равно смотреть, что окажется эффективнее. Хотя я честно говоря это частенько встречал для SELECT-ов с большим уровнем подзапросов и связей, для UPDATE особой разницы не ощущал.

P.S. Кстати насчет долгих UPDATE-ов можно задать пару вопросиков автору топика:
1. Какой COMMIT ACTION задан у глобальной времянки ?
2. Лежат ли временный файлы ASA на быстром носителе ?
3. Какие значения стоит в опциях БД у параметров: Checkpoint_Time и Recovery_Time ?

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase


Большое спасибо за рекомендации
Сегодня попробую и сообщю результаты
Checkpoint_Time =60
Recovery_Time =2 , то есть по умолчанию
БД крутится на сервере, то есть HDD сервера, это консолидированная БД, собирающая данные от Камчатки до Калининрада с использованием репликации счерез почту
Увы, первый вопрос мне не очень понятен.
Создание таблицы идет в процедуре

create global temporary table rm.@Contract(
ID char(36) not null,
ID_Branch char(36) not null,
ID_InsuranceCategory char(36) null,
ContractNumber varchar(50) null,
SigningDate timestamp null,
DateBegin timestamp null,
DateEnd timestamp null,
SumPaymentBrutto numeric(23,8) null,
"In" integer null,
primary key( ID) ,
) on commit preserve rows;
Дпнные в эту таблицу первично, кроме "In" закачиваются через прокси из MS SQL, а затем перед дальнейшей обработкой, связанной с формированием XML, заполняется поле "In" из родной таблицы ASA.
Я уже давно работаю с ASA и меня всегда радовал оптимизаторв отличие от мучений в MS SQL, но вот наступил на грабли, а может уже устал к вечеру.
Еще раз большое спасибо

ASCRUSВы ответили на первый вопрос - это:
авторon commit preserve rows

По моему разумению есть смысл:

Во первых эту времянку сделать вместо транзакционной как NOT TRANSACTIONAL - скорость существенно увеличится, так как не будет затрат на запись в checkpoint лог, проверок коммитов, откатов и прочего (фактически получим аналог ISAM таблиц MySQL).

Во вторых увеличить RECOVERY_TIME - 2 минуты для БД, имеющих на борту массовые апдейты или удаления чрезвычайно мало, так как параметр этот требует от сервера, что в случае его падения, он должен восстановить БД в пределах 2 минут, что естественно с одной стороны по любому не реально в случае ROLLBACK на UPDATE огромного кол-ва записей во время падения сервера, а во вторых в разы замедляет работу из за того, что сервер из за этих несчастных 2 минут перестраховывается и непрерывно сбрашивает с кэша записываемые страницы в БД, вместо того чтобы работать с ними в памяти.
В общем здесь желательно здраво подходить к установке данного параметра и установить его на более реальные значения, которые оптимально будут выбирать между скоростью работы и временем восстановления. Я бы к примеру посоветовал как минимум поставить RECOVERY_TIME на 20-30 минут.

www.rusug.ru - портал русскоязычной группы пользователей Sybase

Сегодня не успел попробовать все Ваши рекомендации.
Как мне рекомендовали - во глобальной временной таблице сделал первичный ключ по полю Contract. Увы не помогло.
Помогло
Создал временну таблицу с 2 полями из основной таблицы ASA
а затем Update

select "IN",number into #r from polago
update @Contract as a,#r as b set a."in" = b."IN" where contractnumber = number

Получил очень приемлемое время ~ 7 мин

Ваши рекомендации попробую завтра