-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
переполнение сегмента отката
- Автор темы iceman
- Дата начала
iceman
говнокодер
переполняются архивные журналы из-за большого кол-ва не зафиксированных записей видать, мне посоветовали по чаще делать commit;
http://paste.org/pastebin/view/22695
http://paste.org/pastebin/view/22695
Falc
Новичок
iceman
>>переполняются архивные журналы из-за большого кол-ва не зафиксированных записей видать, мне посоветовали по чаще делать commit;
1. Архивные логи не могут переполнится они ничем не лимитированы.
2. Чем больше комитов тем больше архивлогов.
3. А че это за простыню ты тут запостил?
>>переполняются архивные журналы из-за большого кол-ва не зафиксированных записей видать, мне посоветовали по чаще делать commit;
1. Архивные логи не могут переполнится они ничем не лимитированы.
2. Чем больше комитов тем больше архивлогов.
3. А че это за простыню ты тут запостил?
iceman
говнокодер
pilot911
Falc
есть другой код для импорта?
в принципе все просто, импортнуть из .дбф во временную таблицу и раскидать в общую КЛАДР, отключив индексы и фк ключи.
> 2. Чем больше комитов тем больше архивлогов.
ХМ!
1. Архивные логи не могут переполнится они ничем не лимитированы.
объемом жесткого диска.
Falc
есть другой код для импорта?
в принципе все просто, импортнуть из .дбф во временную таблицу и раскидать в общую КЛАДР, отключив индексы и фк ключи.
> 2. Чем больше комитов тем больше архивлогов.
ХМ!
1. Архивные логи не могут переполнится они ничем не лимитированы.
объемом жесткого диска.
iceman
говнокодер
Falc
ты имеешь ввиду не таскать данные туда сюда?
либо при импорте файла .dbf во временную таблицу класть в таком виде, чтобы ничего не нужно было в запросе дописывать???
- переписывать будет сложнее, задача этого не стоит =)
самое тормазное место - это перегон из временной таблицы в общую - улиц, записей много, сервер крехтит.
если ты любитель бросаться громкими словечками типа "пиши грамотный код" а сам не понимаешь в чем причина, либо никогда не делал этого, то разговор окончен
Кайта и мануал есесно читаю, в "свободное время"
ты имеешь ввиду не таскать данные туда сюда?
либо при импорте файла .dbf во временную таблицу класть в таком виде, чтобы ничего не нужно было в запросе дописывать???
- переписывать будет сложнее, задача этого не стоит =)
самое тормазное место - это перегон из временной таблицы в общую - улиц, записей много, сервер крехтит.
если ты любитель бросаться громкими словечками типа "пиши грамотный код" а сам не понимаешь в чем причина, либо никогда не делал этого, то разговор окончен
Кайта и мануал есесно читаю, в "свободное время"
Falc
Новичок
iceman
Ты пришел на форум, выкатил простыню кода, хочешь чтобы в нем кто-то разобрался и указал на ошибку. У меня лично нет ни малейшего желания копаться в твоем коде. Если бы передо мной стояла такая задача я бы сделал INSERT SELECT, вставка миллиона записей в таблицу без индексов это несколько секунд, дальше все зависит от селекта. т.е. тупо нужно оптимизировать селект. Если оптимизировать не можешь то кури советы из первой страницы топика.
Ты пришел на форум, выкатил простыню кода, хочешь чтобы в нем кто-то разобрался и указал на ошибку. У меня лично нет ни малейшего желания копаться в твоем коде. Если бы передо мной стояла такая задача я бы сделал INSERT SELECT, вставка миллиона записей в таблицу без индексов это несколько секунд, дальше все зависит от селекта. т.е. тупо нужно оптимизировать селект. Если оптимизировать не можешь то кури советы из первой страницы топика.
iceman
говнокодер
Falc
я сделал insert+select, ошибок не возникало, пока
не, ну нечего нового ты не сказал, грамотней запрос не написать, индексы проставил...
ед. решение которое я вижу это изменить структуру временных таблиц, что значит нужно поменять импортер файлов из .dbf
а там большая попа, задача таких трудозатрат не стоит, если только не грянит гром =)
если бы писал с нуля, то может быть и учел бы это...
всем пасиба =)
p/s мб может есть функция понижающая приоритет процесса, сессии. пусть обновляется по дольше, но главное чтобы другим работать не мешало.
я сделал insert+select, ошибок не возникало, пока
не, ну нечего нового ты не сказал, грамотней запрос не написать, индексы проставил...
ед. решение которое я вижу это изменить структуру временных таблиц, что значит нужно поменять импортер файлов из .dbf
а там большая попа, задача таких трудозатрат не стоит, если только не грянит гром =)
если бы писал с нуля, то может быть и учел бы это...
всем пасиба =)
p/s мб может есть функция понижающая приоритет процесса, сессии. пусть обновляется по дольше, но главное чтобы другим работать не мешало.
Falc
Новичок
>>p/s мб может есть функция понижающая приоритет процесса, сессии. пусть обновляется по дольше, но главное чтобы другим работать не мешало.
Как раз проблема в том что она медленно работает, чем медленнее работает тем больше вероятность нарваться на ошибку "snapshot too old".
Ошибка появляется тогда когда за время выполнения SELECTA в базу было занесено изменений больше чем вмещается в ролбек сегменте. Поэтому коммиты тут в общем-то не причем.
Как раз проблема в том что она медленно работает, чем медленнее работает тем больше вероятность нарваться на ошибку "snapshot too old".
Ошибка появляется тогда когда за время выполнения SELECTA в базу было занесено изменений больше чем вмещается в ролбек сегменте. Поэтому коммиты тут в общем-то не причем.
iceman
говнокодер
> Ошибка появляется тогда когда за время выполнения SELECTA в базу было занесено изменений больше чем вмещается в ролбек сегменте. Поэтому коммиты тут в общем-то не причем.
ну кол-во информации в селекте уже не изменить...?
-~{}~ 23.09.10 23:06:
ошибок и не каких не происходило, просто бд повисала, но процесс работал, после очистки архивных журналов, база отвисла, а процесс как работал так и работал до конца...
ну кол-во информации в селекте уже не изменить...?
-~{}~ 23.09.10 23:06:
ошибок и не каких не происходило, просто бд повисала, но процесс работал, после очистки архивных журналов, база отвисла, а процесс как работал так и работал до конца...