Страница 1 из 1
обрыв длинной транзакции на изменение данных
Добавлено: 21 апр 2005, 08:30
ponyol
Доброго дня!
Вот такая ситуация. Запустил неделю назад процедуру на изменение данных в таблице на 2,5 млн. строк (это я экспериментами занимаюсь). Эта процедура до сих пор продолжается, загрузив один проц на 90% (это все под линухом fb 1.5.2, процедура запущена в консоли с помощью isql). Можно ли оборвать этот процесс, при этом сохранив уже измененные данные этой процедурой? Может запустить какой нить хитрый селект с определенными параметрами транзакции, который сможет прочитать измененные данные?
Добавлено: 21 апр 2005, 12:53
Merlin
Нет и Нет.
Советы на будущее:
1. Нехрен гонять неотлаженые процедуры и запросы на боевом сервере.
2. Запросы внутри процедуры после написания проверять отдельно и поштучно, как и все прочие, впрочем, на тренировочной копии. Смотреть планы, думать, оптимизировать. А потом уже создавать процедуру в целом.
Добавлено: 21 апр 2005, 13:29
ponyol
Merlin писал(а):Нет и Нет.
А жаль
Merlin писал(а):Советы на будущее:
1. Нехрен гонять неотлаженые процедуры и запросы на боевом сервере.
Серверу это не помешало - раз, а гонять больше негде - два.
Merlin писал(а):2. Запросы внутри процедуры после написания проверять отдельно и поштучно, как и все прочие, впрочем, на тренировочной копии. Смотреть планы, думать, оптимизировать. А потом уже создавать процедуру в целом.
Вот задача эксперимента как раз и состояла в том, что бы проверить именно этот объем данных и именно на этих запросах. А вот делаю я, есно, на копии, знаем - плавали.
ЗЫ. Видимо эксперимент не удался.
Добавлено: 21 апр 2005, 13:40
Ivan_Pisarevsky
Серверу это не помешало - раз, а гонять больше негде - два.
Что мешает поставить ФБ на свой десктоп и гонять вдоль и поперек... странное отношение к боевым БД...
Добавлено: 21 апр 2005, 13:53
Merlin
ponyol писал(а):
Вот задача эксперимента как раз и состояла в том, что бы проверить именно этот объем данных и именно на этих запросах. А вот делаю я, есно, на копии, знаем - плавали.
ЗЫ. Видимо эксперимент не удался.
Ясен перец. Потому что в результате эксперимента ты всего лишь убедился, что эта гроздь запросов содержит как минимум 1 хреновый. Но не не знаешь сколько и какие хреновые, а какие - нет. Тогда на хрена был такой эксперимент?
Добавлено: 21 апр 2005, 14:26
ponyol
Ivan_Pisarevsky писал(а):Что мешает поставить ФБ на свой десктоп и гонять вдоль и поперек... странное отношение к боевым БД...
Ни чего не мешает, только декстопа у меня нет, только сервер

. А с чего вы все взяли, что это боевая БД. Она (боевая) работает в нормальном режиме на втором процике под IB

.
Добавлено: 21 апр 2005, 14:34
ponyol
Merlin писал(а):Ясен перец. Потому что в результате эксперимента ты всего лишь убедился, что эта гроздь запросов содержит как минимум 1 хреновый. Но не не знаешь сколько и какие хреновые, а какие - нет. Тогда на хрена был такой эксперимент?
А вот как раз и не ясен!!! Вопрос не в запросах, а в той куче записей, которые невозможно разбить в какие-нить подгруппы для update. С ними можно работать только в общей массе. И эксперимент показал, что это может продолжаться бесконечно.
Обидно другое.
Я загнал эту таблицу в текстовый файл и , написав на питоне скрипт, сделал с ней тоже самое. Скрипт работал всего лишь 2,5 часа!!! Вот и пойми, что лучше. На всяк случай, в таблице нет не индексов, не триггеров, это просто голая таблица.
Добавлено: 21 апр 2005, 14:52
Merlin
ponyol писал(а):
А вот как раз и не ясен!!! Вопрос не в запросах, а в той куче записей, которые невозможно разбить в какие-нить подгруппы для update. С ними можно работать только в общей массе. И эксперимент показал, что это может продолжаться бесконечно.
Мозги имеешь ты нам, ну просто самозабвенно. Чтоп тупой апдейт несчастных 2.5 лимонов записей шол неделю? Бабушке своей сказки рассказывай. И на селекты в процедуре смотри. А также на разрыв OIT-OAT и sweep interval в базе.
ponyol писал(а):
Обидно другое.
Я загнал эту таблицу в текстовый файл и , написав на питоне скрипт, сделал с ней тоже самое. Скрипт работал всего лишь 2,5 часа!!!
Сравниваем ж-у с пальцем? Текстовый файл с работой реляционной версионной СУБД со всеми пост-эффектами управления транзакциями, мусором, оптимизатором запросов? Ну-ну.
Добавлено: 21 апр 2005, 15:24
ponyol
Merlin писал(а):Мозги имеешь ты нам, ну просто самозабвенно. Чтоп тупой апдейт несчастных 2.5 лимонов записей шол неделю? Бабушке своей сказки рассказывай. И на селекты в процедуре смотри. А также на разрыв OIT-OAT и sweep interval в базе.
Ну не совсем тупой, вернее совсем не тупой, а вот про sweep interval в базе я не подумал, согласен.
Merlin писал(а):Сравниваем ж-у с пальцем? Текстовый файл с работой реляционной версионной СУБД со всеми пост-эффектами управления транзакциями, мусором, оптимизатором запросов? Ну-ну.
Ничего я не сравнивал, просто было любопытно посмотреть

.
Спасибо всем за внимание и общение. Тему можно закрыть до следующего эксперимента

, тем более от темы мы давно отклонились.
Добавлено: 21 апр 2005, 16:35
Ivan_Pisarevsky
На всяк случай, в таблице нет не индексов, не триггеров, это просто голая таблица.
Индексация, говорят, погает слехка ускорить процесс

ежель индексы подумамши расставить
Этж как без собственного десктопа работать? я, например, не могу соредоточиться под вой серверных ветродуев...
Добавлено: 21 апр 2005, 17:57
ponyol
Ivan_Pisarevsky писал(а):Этж как без собственного десктопа работать? я, например, не могу соредоточиться под вой серверных ветродуев...
Бездисковая станция в кабинете
