Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2003.06.26;
Скачать: [xml.tar.bz2];

Вниз

UPDATE НА БОЛЬШОЙ ОБЪЕМ ДАННЫХ В INTERBASE   Найти похожие ветки 

 
Александр Николаевич   (2003-05-30 12:50) [0]

Нужна помощь!
Есть следующий запрос на UPDATE.

UPDATE OS_ALLOCACCOUNT A
SET A.DATE_MOVE =
(SELECT D.DATE_MOVE FROM OS_DVIG D WHERE D.ID = A.IDDVIG)


Так вот выполняется БОЛЕЕ 10 мин на хорошей машине.
D.ID - PRIMARY KEY
A.IDDVIG - FOREIGN KEY
OS_DVIG - record count 37 000
OS_ALLOCACCOUNT - record count 5 000
Не очень то и много.


 
Александр Николаевич   (2003-05-30 12:52) [1]

Sorry!
Вопрос то забыл написать! Как оптимизировать скорость?????


 
Zacho   (2003-05-30 12:54) [2]

Смотри http://www.ibase.ru/devinfo/updsame.htm


 
Соловьев   (2003-05-30 12:54) [3]

а ХП не пробовал?


 
Александр Николаевич   (2003-05-30 12:58) [4]

А без ХП никак???
А использование Yafill or Firebird никак не помогет? В Yafill можно ведь строить планы на UPDATE


 
Соловьев   (2003-05-30 13:01) [5]


> А без ХП никак???

а что в них плохого?


 
Ann   (2003-05-30 13:03) [6]

я тоже считаю, что ХП лучше использовать да и отработает быстрее..


 
Александр Николаевич   (2003-05-30 13:04) [7]

Привязываешся к конкретной СУБД. При переходе на другое СУБД(SQL, ORACLE) придется много чего перелопачивать


 
Zacho   (2003-05-30 13:04) [8]


> Александр Николаевич (30.05.03 12:58)

Imho, если это единичная операция, то можно и 10 мин. подождать, а если подобное требуется постоянно, то ХП типа описанных в http://www.ibase.ru/devinfo/updsame.htm - самое то.


 
Zacho   (2003-05-30 13:06) [9]


> Александр Николаевич (30.05.03 13:04)

При переходе на другую СУБД в любом случае придется много чего перелопачивать, иначе получится система одинаково неэффиктивно работающая на всех СУБД.


 
stone   (2003-05-30 13:09) [10]

А интербэйз такие кострукции поддерживает?

UPDATE OS_ALLOCACCOUNT
SET DATE_MOVE = D.DATE_MOVE FROM OS_DVIG D INNER JOIN OS_ALLOCACCOUNT A ON D.ID = A.IDDVIG




 
Александр Николаевич   (2003-05-30 13:11) [11]

>stone
В том то и дело, что нет


 
kaif   (2003-05-30 17:00) [12]

Сама конструкция запроса медленная.
Она проходит 5000 записей в одной таблице и для того, чтобы заменить значение каждый раз вызывает SELECT к таблице, в которой 37000 записей.
Надеюсь, что хотя бы, что поле ID это просто PRIMARY KEY и поиск идет по индексу.
Предлагаю сделать иначе.
Нужно сделать хранимую процедуру, вней конструкцию FOR с объединением таблиц и UPDATE 1 записи внутри цикла.

create procedure quick_update
as
declare variable tmp_id integer; //это уточните
declare variable tmp date;
begin
for select A.ID, D.DATE_MOVE
from OS_ALLOCACCOUNT A, OS_DVIG D
where WHERE D.ID = A.IDDVIG
into :tmp_id, :tmp _date
do
UPDATE OS_ALLOCACCOUNT
SET DATE_MOVE = :tmp_date
WHERE ID = :tmp_id;
end

Здесь использован первичный ключ таблицы OS_ALLOCACCOUNT - условно ID. В вашем запросе он не используется, поэтому я его вынужден был додумать.
Но идея, я думаю, Вам ясна.

Остнется лишь запустить потом процедуру

execute procedure quick_update;

Я думаю, что это должно сработать секунд за 5 - 10.


 
Zacho   (2003-05-30 17:13) [13]


> kaif © (30.05.03 17:00)

На http://www.ibase.ru/devinfo/updsame.htm есть парочка более быстрых вариантов :-)


 
kaif   (2003-05-31 01:16) [14]

2 Zacho © (30.05.03 17:13)

Спасибо за ссылку. Очень ценная и компактная статья. Правда там мой вариант приведен (изменение update и select местами). Но я впервые узнал о возможности обращения as cursor. И вообще не знал про поле RDB$DB_KEY. Хотя я пока в сомнении насчет версионного механизма и контекста транзакции. Будет ли это всегда работать (RDB$DB_KEY)?


 
Zacho   (2003-05-31 01:26) [15]


> kaif © (31.05.03 01:16)

Про RDB$DB_KEY могу дать еще пару ссылок http://www.cvalde.com/document/mysteriousDbKey.htm
http://www.cvalde.com/document/practical_use_of_the_rdb.htm


 
kaif   (2003-05-31 05:12) [16]

2 Zacho © (31.05.03 01:26)
совершенно потрясающая информация...
именно для задач массовых update-ов.
Но пока мне не удается получить значения RDB$DB_KEY из своих таблиц. Сервер Yaffil ss 821. Все строки select-а возвращают одну и ту же закорюку, причем в каждой таблице свою.
Но я еще поэкспериментирую. Может IBX-ы неверный тип поля используют...


 
Zacho   (2003-05-31 13:34) [17]


> kaif © (31.05.03 05:12)
> Но пока мне не удается получить значения RDB$DB_KEY из своих
> таблиц. Сервер Yaffil ss 821. Все строки select-а возвращают
> одну и ту же закорюку, причем в каждой таблице свою

C помощью IBX или инструмента типа IBExpert и не удастся. Почему - не знаю, я и сам пока плохо понимаю, что такое RDB$DB_KEY и с чем его едят :-)
Попробуй стандартный isql.exe - будешь приятно удивлен.



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2003.06.26;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.48 MB
Время: 0.042 c
8-84445
Deedlit
2003-03-10 11:36
2003.06.26
Проблемы с SDK BSPlayer а


3-83936
needle
2003-06-04 08:15
2003.06.26
использование памяти MS SQL server 2000


1-84241
SergeY
2003-06-12 22:56
2003.06.26
Как обратиться к компоненту в цикле через переменную?


9-83839
MRB_SPB
2003-01-16 12:49
2003.06.26
Геометрия


3-83856
Dimaz-z
2003-06-01 10:44
2003.06.26
Как выстроить по русскому алфивиту содержимое базы данных?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский