Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Informix [игнор отключен] [закрыт для гостей] / Как избежать Long transaction / 25 сообщений из 32, страница 1 из 2
07.06.2007, 18:25
    #34582130
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Ситуация следующая:
- есть некая таблица (довольно большая, порядка 10 млн. записей, размер записи 25 байт, суммарный размер таблицы порядка 180Мб)
- есть необходимость "перегнать" ее в другую таблицу (сделав INSERT INTO ... SELECT * FROM ...) с аналогичной структурой

Сейчас при попытке выполнить такой перенос происходит отвал из за Long transaction.

Понятно, что можно сделать это процедурой, в которой переносить частями. Этого хотелось бы (по возможности) избежать (просто потому что лениво :)), так как процесс - разовый).

Какие есть варианты?
...
Рейтинг: 0 / 0
07.06.2007, 18:47
    #34582194
sysmaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Добавить журналов или отключить журналирование.
...
Рейтинг: 0 / 0
07.06.2007, 21:06
    #34582451
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
sysmasterДобавить журналов или отключить журналирование.Я совсем не админ, поэтому прошу простить за, возможно, дурацкие вопросы.
1. Насколько нужно увеличить размеры/количество файлов журнала?
2. Как посмотреть текущие настройки?
3. Чем чревато отключение журналирования (задача будет выполнятся на сервере монопольно)?
4. Как отключить журналирование и как потом включить его обратно?
...
Рейтинг: 0 / 0
08.06.2007, 00:05
    #34582672
Чемберлен
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Упрощенны ответы:

1. Насколько нужно увеличить размеры/количество файлов журнала?

Обычно (зависит от параметров конфигурации LTXHWM) достаточно, чтобы суммарный объем журналов был в два с лишним раза больше, чем объем изменений, генерируемых транзакцией

2. Как посмотреть текущие настройки?

Параметры:

onstat -c

Журналы:

onstat -l

3. Чем чревато отключение журналирования (задача будет выполнятся на сервере монопольно)?

Если других пользователей, которым нужны транзакции с этой базой, нет, и не задействована репликация HDR и/или распределенные транзакции - ничем, в прниципе. В случае сбоя сервера по ходу - повторите сначала :)

4. Как отключить журналирование и как потом включить его обратно?

Отключить:

- Установить в ONCONFIG

TAPEDEV /dev/null

(запомнив старое значение)

- Выполнить

ontape -s -L 0 -N ваша_база

Включить:

- Выполнить

ontape -s -L 0 -U ваша_база

(если нужна небуферизованная журнализация)

- Вернуть старое значение TAPEDEV

TAPEDEV можно и не менять, если реальное архивирование уровня 0 два раза вас не смущает...
...
Рейтинг: 0 / 0
08.06.2007, 01:08
    #34582720
Julian
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
По-моему, на первом ontape можно сэкономить - отключить журналирование утилитой onmonitor (меню database, выбрать БД, ctrl+b,...). Конечно, как было сказано другими словами, сессии, в которых встретится BEGIN WORK, посыпятся.
А почему бы просто в SELECT не добавить WHERE, делящий количество записей примерно пополам (можно даже выполнить предварительно что-что вроде SELECT AVG(ID) или SELECT MIN(ID) + (MAX(ID) - MIN(ID))/2) и перегнать записи двумя командами INSERT?
...
Рейтинг: 0 / 0
08.06.2007, 09:38
    #34582998
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
...
Рейтинг: 0 / 0
08.06.2007, 13:35
    #34583863
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
JulianПо-моему, на первом ontape можно сэкономить - отключить журналирование утилитой onmonitor (меню database, выбрать БД, ctrl+b,...). Конечно, как было сказано другими словами, сессии, в которых встретится BEGIN WORK, посыпятся.
А почему бы просто в SELECT не добавить WHERE, делящий количество записей примерно пополам (можно даже выполнить предварительно что-что вроде SELECT AVG(ID) или SELECT MIN(ID) + (MAX(ID) - MIN(ID))/2) и перегнать записи двумя командами INSERT?А если записей много и половина тоже не влезет? :))
Я же выше писал - можно сделать процедуру. Но лениво :)), поэтому ищу варианты попроще!
...
Рейтинг: 0 / 0
08.06.2007, 13:36
    #34583872
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Журавлев Денисraw table

http://www.sql.ru/forum/actualthread.aspx?tid=188907&hl=raw#1589712 А чем это мне поможет? У меня и исходная и итоговая таблицы - постоянные, обыкновенные.
...
Рейтинг: 0 / 0
08.06.2007, 13:58
    #34583962
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Евгений Фадеев Журавлев Денисraw table

http://www.sql.ru/forum/actualthread.aspx?tid=188907&hl=raw#1589712 А чем это мне поможет? У меня и исходная и итоговая таблицы - постоянные, обыкновенные.
drop index -- all indexes, cntrs, trigs from target
alter table target set mode raw ...
insert into target select from source
alter table target set ...
create index on target
...
Рейтинг: 0 / 0
08.06.2007, 15:40
    #34584424
Andron
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Кстате начиная с IDS 10.00.xC6 raw table поддерживает индексы.
...
Рейтинг: 0 / 0
08.06.2007, 18:45
    #34585019
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
AndronКстате начиная с IDS 10.00.xC6 raw table поддерживает индексы.У меня 9.40
...
Рейтинг: 0 / 0
18.06.2007, 20:56
    #34603054
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Так, ROW с загрузкой данных в таблицу помогло (получилось быстро и красиво).
Теперь складывается на CREATE UNIQUE CLUSTER INDEX... Я так понимаю выход только в увеличении размера/количества журнальных файлов?
...
Рейтинг: 0 / 0
18.06.2007, 21:28
    #34603100
vasilis
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Евгений ФадеевТеперь складывается на CREATE UNIQUE CLUSTER INDEX... Я так понимаю выход только в увеличении размера/количества журнальных файлов?
А зачем именно кластерный индекс ? Он сильно увеличивает объем работы (по переупорядочиванию всей таблицы) и ,соответственно, объем логов...
И в чем проблема увеличит все таки логи ? Мне кажется, что у вас их совсем немного.
Строили индексы на 90млн. таблице и хватало логов на гиг (если не ошибаюсь)
...
Рейтинг: 0 / 0
19.06.2007, 08:48
    #34603540
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Евгений ФадеевТак, ROW с загрузкой данных в таблицу помогло (получилось быстро и красиво).
Теперь складывается CLUSTER -- я бы никогда этим не пользовался, абсолютно не нужно. Ну и особенность информикса что кластерность после создания не поддерживается (insert,update,delete), т.е. он таблица упорядочена только в момент create index cluster.
...
Рейтинг: 0 / 0
19.06.2007, 09:05
    #34603562
sysmaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
vasilis
И в чем проблема увеличит все таки логи ? Мне кажется, что у вас их совсем немного.

Евгений, покажите значение параметров LOGFILES и LOGSIZE.
...
Рейтинг: 0 / 0
19.06.2007, 10:59
    #34603924
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
sysmaster vasilis
И в чем проблема увеличит все таки логи ? Мне кажется, что у вас их совсем немного.

Евгений, покажите значение параметров LOGFILES и LOGSIZE.Проблема в увеличении логов состоит в том, что я не админ, а разработчик. И просить админов что-то там поменять - до определенной степени геморройно (по возможности я бы предпочел этого избежать).
Код: plaintext
1.
2.
LOGFILES         34               # Number of logical log files
LOGSIZE          50000            # Logical log size (Kbytes)
...
Рейтинг: 0 / 0
19.06.2007, 11:01
    #34603935
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Журавлев ДенисCLUSTER -- я бы никогда этим не пользовался, абсолютно не нужно.Ну, здесь можно поспорить...
Журавлев Денис Ну и особенность информикса что кластерность после создания не поддерживается (insert,update,delete), т.е. он таблица упорядочена только в момент create index cluster.Это что, шутка?! :)
...
Рейтинг: 0 / 0
19.06.2007, 11:17
    #34604017
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
sysmasterЕвгений, покажите значение параметров LOGFILES и LOGSIZE.Что употребляете?
LOGFILES specifies the number of logical-log files that the database server creates during disk initialization.
LOGSIZE specifies the size that is used when logical-log files are created.
...
Рейтинг: 0 / 0
19.06.2007, 11:20
    #34604036
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Евгений Фадеев Журавлев ДенисCLUSTER -- я бы никогда этим не пользовался, абсолютно не нужно.Ну, здесь можно поспорить...Пользы от IOT -- мало, в случае с информиксом еще меньше. Спорить не буду, инет глючит, все isp уроды, их клиенты тоже.

Евгений ФадеевЭто что, шутка?! :)А ты смайлик видишь? Я нет. RTFM.
...
Рейтинг: 0 / 0
19.06.2007, 11:34
    #34604105
Евгений Фадеев
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Журавлев Денис Евгений Фадеев Журавлев ДенисCLUSTER -- я бы никогда этим не пользовался, абсолютно не нужно.Ну, здесь можно поспорить...Пользы от IOT -- мало, в случае с информиксом еще меньше.А можно чуть подробнее?
У меня вполне стандартная ситуация: таблица-очередь. Выборки (и вообще вся работа) идут по ключу. Монотонно вверх. С моей точки зрения - выгода от кластерного индекса вполне очевидная.

Журавлев Денис Евгений ФадеевЭто что, шутка?! :)А ты смайлик видишь? Я нет. RTFM.Охренеть! А зачем они тогда вообще это делали?!
...
Рейтинг: 0 / 0
19.06.2007, 12:08
    #34604267
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Евгений ФадеевА можно чуть подробнее?
У меня вполне стандартная ситуация: таблица-очередь. Выборки (и вообще вся работа) идут по ключу. Монотонно вверх. С моей точки зрения - выгода от кластерного индекса вполне очевидная.
Как вообще индексы работают? Надо спустится к искомому значению по b-дереву, например за 5 шагов (blevel=5), далее мы найдем "rowid" и пойдем за строк(ой)ми таблицы (7-й шаг, если строк несколько то 8, 9-й шаги).
Если ищем несколько значений в индексе, то мы перейдем к след-у значению индекса (10-й шаг), найдем "rowid", и снова пойдем в таблицу (11,12,13). При IOT организации например в оракле, строки лежат прямо в индексе, т.е. 7,8,9,11,12,13 шаги не нужны.
В случае информикса они (переход в таблицу по rowid) ВСЕГДА делаются. Но для кластеризованной таблицы из-за упреждающего чтения высока вероятность что нужные строки уже в памяти.

Да, это все про деатачид индексы.


Журавлев ДенисОхренеть! А зачем они тогда вообще это делали?!Думаю маркетинговая галочка. У всех есть, а у нас нет. Надо чтоб было.

Я в общем не пользуюсь и не вижу никого кто пользуется, ни в оракле (где iot накладывает опр-е ограничения), ни в информиксе.
...
Рейтинг: 0 / 0
19.06.2007, 12:14
    #34604307
sysmaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Журавлев Денис
sysmasterЕвгений, покажите значение параметров LOGFILES и LOGSIZE.Что употребляете?
LOGFILES specifies the number of logical-log files that the database server creates during disk initialization.
LOGSIZE specifies the size that is used when logical-log files are created.

И всем же я ошибся?
...
Рейтинг: 0 / 0
19.06.2007, 12:18
    #34604329
Журавлев Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
sysmasterИ всем же я ошибся?Командой onparams логи любого размера можно добавить после инициализации, т.е. LOGFILES*LOGSIZE<>размер всего журнала.
Просить надо onstat -l
...
Рейтинг: 0 / 0
19.06.2007, 12:46
    #34604455
Тан
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Журавлев Денис sysmasterИ всем же я ошибся?Командой onparams логи любого размера можно добавить после инициализации, т.е. LOGFILES*LOGSIZE<>размер всего журнала.
Просить надо onstat -l
неправда, onparams правит onconfig.
...
Рейтинг: 0 / 0
19.06.2007, 12:50
    #34604479
vasilis
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как избежать Long transaction
Евгений Фадеев Журавлев Денис Евгений Фадеев Журавлев ДенисCLUSTER -- я бы никогда этим не пользовался, абсолютно не нужно.Ну, здесь можно поспорить...Пользы от IOT -- мало, в случае с информиксом еще меньше.А можно чуть подробнее?
У меня вполне стандартная ситуация: таблица-очередь. Выборки (и вообще вся работа) идут по ключу. Монотонно вверх. С моей точки зрения - выгода от кластерного индекса вполне очевидная.

Насчет АБСОЛЮТНОЙ безполезности я бы тоже поспорил :)
но соглашусь, что используют это крайне редко. Кстати, это один из способов заставить физически перезаписаться всю таблицу (устранение избыточной фрагментации, убрать множество версий после alter table и т.п.).
Вот как описывается кластерный индекс в литературе:
--------------
Кластерные индексы
Информация, хранящаяся в базе данных извлекается с жесткого диска блоками (секциями дискового пространства). С помощью кластеризации можно заставить данные размещаться на диске в порядке, предписанном индексом. Это может повысить эффективность извлечения данных, потому что оно будет происходить в порядке, близком к тому, в котором они извлекаются по индексу.
В нашем примере, если кластерный индекс построен по полю lname, строки с данными будут физически упорядочены по полю lname. Оператор SELECT, извлекающий большое количество записей из таблицы customer, в порядке сортировки поля lname будет работать более эффективно, особенно, если таблица большая.
Кластерный индекс изменяет физическое расположение данных на диске. Поэтому в таблице может существовать только один кластерный индекс. Кластеризация не поддерживается (не обновляется) при добавлении данных в таблицу или обновлении существующих данных. Поэтому кластерные индексы наиболее эффективны при использовании в часто используемых для чтения статических таблицах и менее эффективны в таблицах динамических.
Хотя кластерность и не изменяется при добавлении или обновлении данных в таблице, кластерный индекс может быть рекластеризован с помощью оператора:
ALTER INDEX имя_индекса TO CLUSTER
Для поддержания эффективности кластерного индекса, имеет смысл часто обновлять кластерный индекс, построенный по нестатической таблице.
Во время выполнения оператора ALTER INDEX TO CLUSTER сервер создаст на диске копию всей таблицы в индексном порядке перед удалением старой таблицы. Необходимо обеспечить достаточное количество дискового пространства перед проведением этой операции.
--------------
...
Рейтинг: 0 / 0
Форумы / Informix [игнор отключен] [закрыт для гостей] / Как избежать Long transaction / 25 сообщений из 32, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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