Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Deng
Member

Откуда:
Сообщений: 35
Доброе утро.

Попытаюсь изложить суть проблемы.
Есть таблица в MSSQL, куда с интервалом в пару секунд падают значения определенных параметров:
Имя параметра                  Время добавления                                  Значение
	а1				00:00:01				28.54687
	а2				00:00:01				23.54687
	а3				00:00:01				20.54687
	...
	а270		        	00:00:01				15.54687
	
	а1				00:00:03				18.54687
	а2				00:00:03				13.54687
	а3				00:00:03				22.54687
	...
	а270				00:00:03				17.54687
	........

Необходимо эти данные перенести в таблицу Oracle.
В Oracle запущен Job, который запускает процедуру, где:
1. через каждые 10 минут делается запрос в БД MSSQL и вытягиваются все данные за этот промежуток времени;
2. полученные значения вставляются во временную таблицу Oracle (GLOBAL TEMPORARY TABLE (ON COMMIT DELETE ROWS));
3. делается SELECT из временной таблицы с агрегированием по 10 секунд значения переменных (а1, а2, ..., а270);
4. данные SELECTа разбираются, а именно, за каждые 10 секунд набираются значения всех переменных и делается INSERT в таблицу БД Oracle:
         Время	        	а1		а2		а3		...	а270
	00:00:00		28.5458		20.458		18.8878			19.4522
	00:00:10		30.6458		21.458		23.4578			24.4622

Т.е. при разборе данных SELECTа я делаю

INSERT INTO TABLE (Время,а1,а2,...,а270)
VALUES ('00:00:00',28.5458,20.458,...,19.4522);

INSERT INTO TABLE (Время,а1,а2,...,а270)
VALUES ('00:00:10',30.6458,21.458,...,24.4622);
и т.д. за все 10 минут.

По окончании разбора SELECTа, в случае отсутствия ошибок, делаю COMMIT.

Все работает, но раз в месяц сталкиваюсь с проблемой, когда все мои UNDO файлы переполняются. У меня 4 файла UNDO размером по 4 Гб, авторасширение запрещено.

Как решить проблему с переполнением? Уменьшить временной интервал - взять не 10 минут, а, например, 5? Или...
14 дек 11, 08:01    [11761458]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Deng,

А какие настройки undo retention?
14 дек 11, 08:49    [11761526]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6914
суть-то в чем? раз в месяц приходится переносить больше строк или UNDO заполняется данными другой задачи?
14 дек 11, 08:50    [11761530]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
-2-
Member

Откуда:
Сообщений: 15330
Какой-нибудь джоб перестраивает данные раз в месяц? Например делит на смешно-маленькие партиции.

Сергей Арсеньев
А какие настройки undo retention?
инсерт 8640 широких строк в сутки. Нужно гарантировать года три, чтобы сожрать 16ГБ undo.
14 дек 11, 09:14    [11761605]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Deng
Member

Откуда:
Сообщений: 35
Сергей Арсеньев
А какие настройки undo retention?

NAME = UNDO_RETENTION
TYPE = 3
VALUE = 10800 Sec
ISDEFAULT = FALSE
ISSES_MODIFIABLE = FALSE
ISSYS_MODIFIABLE = IMMEDIATE
ISMODIFIED = FALSE
ISADJUSTED = FALSE

alex-ls
суть-то в чем? раз в месяц приходится переносить больше строк или UNDO заполняется данными другой задачи?

Количество строк всегда примерно одинаково, заполнение UNDO происходит при выполнении из JOBа моей процедуры
(Ошибка: #ERROR: -30036 - ORA-30036: unable to extend segment by 1024 in undo tablespace 'UNDOTBS2' )

-2-
Какой-нибудь джоб перестраивает данные раз в месяц? Например делит на смешно-маленькие партиции.

Нет.
14 дек 11, 10:14    [11761903]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Deng,

Посмотреть сколько транзакций и сколько блоков undo едят (особенно в момент переполнения) в V$Transaction.
14 дек 11, 10:23    [11761954]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
hoarfrost
Member

Откуда: Волгоград
Сообщений: 438
Deng
Как решить проблему с переполнением? Уменьшить временной интервал - взять не 10 минут, а, например, 5? Или...

Например:
1. Уменьшить UNDO_RETENTION (если это можно);
2. Сделать больше UNDO;
3. Периодически создавать новое UNDO, делаеть его UNDO по умолчанию и после удалять предыдущее UNDO (с учётом UNDO_RETENTION);

4. Гуру чего-нибудь ещё посоветуют. :)
14 дек 11, 10:41    [11762050]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6914
Deng
alex-ls
суть-то в чем? раз в месяц приходится переносить больше строк или UNDO заполняется данными другой задачи?

Количество строк всегда примерно одинаково, заполнение UNDO происходит при выполнении из JOBа моей процедуры
(Ошибка: #ERROR: -30036 - ORA-30036: unable to extend segment by 1024 in undo tablespace 'UNDOTBS2' )

советую проверить логгированием... не сам же UNDO заполняется.
14 дек 11, 11:20    [11762404]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Deng
Member

Откуда:
Сообщений: 35
Сергей Арсеньев
Посмотреть сколько транзакций и сколько блоков undo едят (особенно в момент переполнения) в V$Transaction.

На какое поле нужно обратить внимание?

alex-ls
советую проверить логгированием...

Как это можно организовать или где можно посмотреть?
14 дек 11, 12:02    [11762789]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
hoarfrost
Member

Откуда: Волгоград
Сообщений: 438
Кстати, а индексы на таблицу, в которую идёт вставка - есть?
Если нет, то действительно - с чего это UNDO пухнет?
14 дек 11, 12:49    [11763199]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Deng
Member

Откуда:
Сообщений: 35
hoarfrost
Кстати, а индексы на таблицу, в которую идёт вставка - есть?
Если нет, то действительно - с чего это UNDO пухнет?


Индексы есть.
14 дек 11, 13:15    [11763461]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Deng,

used_ublk - количество блоков undo занятых транзакцией.
Если лидер один и зажрал все undo копать его, а если разные то ...

P.S. А индексы по каждому полю свой?
14 дек 11, 15:52    [11765210]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5151
Deng
данные SELECTа разбираются
Deng
Т.е. при разборе данных SELECTа я делаю
INSERT INTO TABLE (Время,а1,а2,...,а270)
VALUES ('00:00:00',28.5458,20.458,...,19.4522);

INSERT INTO TABLE (Время,а1,а2,...,а270)
VALUES ('00:00:10',30.6458,21.458,...,24.4622);
Ты что генеришь insert statements?
И к чему все сложности? Для чего здесь темповая таблица?
Почему ты просто не сделаешь
insert into ... select ... group by
?
Deng
Все работает, но раз в месяц сталкиваюсь с проблемой, когда все мои UNDO файлы переполняются.
Когда возникает ошибка, обычно можно увидеть что её породило. Ты смотрел это в своем случае?

З.Ы. Ты можешь включить autotrace и глянуть сколько генерится undo для твоих statement. Они явно не должны служить причиной переполнения.
14 дек 11, 16:08    [11765378]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6914
Deng
alex-ls
советую проверить логгированием...

Как это можно организовать или где можно посмотреть?

Создаете отдельную таблицу и пишите в нее кол-во вставленных строк в автономной транзакции через пакетную процедуру. У меня ощущение, что Вы вставляете по одной строке в цикле по курсору, судя по первому посту, хотя могу и ошибаться. Как получите ошибку по логам будет видно на каком месте упало и сколько строк при этом вставилось.
14 дек 11, 16:57    [11765924]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
-2-
Member

Откуда:
Сообщений: 15330
alex-ls
Создаете отдельную таблицу...
достаточно и более достоверно, все-таки, диагностировать проблему, когда процесс находится на ней. И главное, менять в коде ничего не надо.
14 дек 11, 17:16    [11766135]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6914
-2-
alex-ls
Создаете отдельную таблицу...
достаточно и более достоверно, все-таки, диагностировать проблему, когда процесс находится на ней. И главное, менять в коде ничего не надо.

вроде JOB, оно может и ночью выполняться и в выходные, по-моему, надо свой код снабжать отладочными сообщениями, которые можно включить, если надо. Конечно, если другие транзакции делают UND,O то логгирование тут не поможет :)
14 дек 11, 17:23    [11766186]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
-2-
Member

Откуда:
Сообщений: 15330
alex-ls
оно может и ночью выполняться и в выходные
проблему отсутствия места можно "притормозить" до понедельника. Можно ее оперативно перехватить триггером и сделать дамп процесса или послать извещение спящему админу и ждать его вмешательства не прерывая проблемную операцию.
14 дек 11, 23:53    [11768132]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6914
-2-
alex-ls
оно может и ночью выполняться и в выходные
проблему отсутствия места можно "притормозить" до понедельника.

Супер :) пусть все остальные задачи ждут пока решится эта...

-2-
Можно ее оперативно перехватить триггером и сделать дамп процесса или послать извещение спящему админу и ждать его вмешательства не прерывая проблемную операцию.

зачем все эти сложности? логгирование своего кода намного удобнее!
15 дек 11, 04:25    [11768415]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Deng
Member

Откуда:
Сообщений: 35
dbms_photoshop
Ты что генеришь insert statements?

Да
dbms_photoshop
Для чего здесь темповая таблица?

На сервере MSSQL хранятся параметры а1, а2,...,а270. Где а1 - температура воды, а2 - температура воздуха и т.д. Т.е. есть в БД MSSQL еще и справочник, где описаны, что такое а1, а2 и прочее. Но сегодня, например, а1 - это температура воды, завтра а1 - может стать температурой воздуха (с изменением справочника MSSQL, естественно).
В БД Oracle есть тоже справочник данных параметров, но он неизменчив. По сути, во временную таблицу попадают данные в виде:
Имя параметра              Время                      Значение
температура воды          00:00:01                  28.54687
температура воздуха      00:00:01                  128.54687

Из этой временной таблицы я делаю селект с привязкой к своему неизменному справочнику, получая индекс параметра (а1, а2,...) и среднее значение параметров за 10 секунд (GROUP BY substr(TO_CHAR(a.DATEANDTIME,'dd.mm.yyyy hh24:mi:ss'),1,18)).
Сделал так, чтобы уменьшить время запроса к серверу MSSQL.
Если я заблуждаюсь, наставьте на путь истинный :-) К критике я адекватен.

dbms_photoshop
Когда возникает ошибка, обычно можно увидеть, что её породило. Ты смотрел это в своем случае?

К сожалению, пока не знаю как и где посмотреть.

dbms_photoshop
З.Ы. Ты можешь включить autotrace и глянуть сколько генерится undo для твоих statement. Они явно не должны служить причиной переполнения.

Хорошо, почитаю как это включить.

alex-ls
У меня ощущение, что Вы вставляете по одной строке в цикле по курсору, судя по первому посту, хотя могу и ошибаться.

Да, вставляю по одной строке. По завершению разбора курсора, делаю COMMIT.

В моем понимании, рост UNDO файлов происходит в результате записи данных на случай отката. Т.е. когда я делаю в цикле INSERT, UNDO будет расти. Почему-то я думал раньше, что выполнение COMMIT по выполнению INSERT, очистит UNDO от данных выполненного INSERT.

Если я буду логгировать и вести запись, что, например, на 88 INSERTе у меня произошло переполнение UNDO, что это даст?
Во всех своих процедурах я веду журнал логов, где фиксирую ошибки, которые возникают в ходе выполнения данных процедур.
Всегда переполнение UNDO возникает, именно, в этой процедуре.
15 дек 11, 07:32    [11768486]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18486
select tablespace_name, retention from dba_tablespaces where contents='UNDO'

Сколько строк-то участвуют в процессе, подробней про выполняемые операторы и средний размер строки? Нет ли удалений, изменений значений -- именно они генерируют много UNDO, только вставка (и очистка временной таблицы по завершению транзакции / TRUNCATE) генерирует мало.

Также покурить значения в V$UNDOSTAT / DBA_HIST_UNDOSTAT
15 дек 11, 07:46    [11768493]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6914
Deng
В моем понимании, рост UNDO файлов происходит в результате записи данных на случай отката. Т.е. когда я делаю в цикле INSERT, UNDO будет расти.

для отката INSERT надо мало UNDO, но много REDO, если упрощенно...

Deng
Почему-то я думал раньше, что выполнение COMMIT по выполнению INSERT, очистит UNDO от данных выполненного INSERT.

полный бред UNDO используется для версионности

Deng
Если я буду логгировать и вести запись, что, например, на 88 INSERTе у меня произошло переполнение UNDO, что это даст?
Во всех своих процедурах я веду журнал логов, где фиксирую ошибки, которые возникают в ходе выполнения данных процедур.
Всегда переполнение UNDO возникает, именно, в этой процедуре.

Надо логгировать действия своего кода. Например :
Вставилось 88 строк в таблицу т1
Обновилось 20 строк в таблице т2
Удалилось 100 строк из таблицы т3.
Общая сумма по расчету 22,54

Сейчас прочитав Ваш текст, я думаю, что вместо временной таблицы у Вас обыкновенная таблица (просто Вы ее назвали временной) и раз в месяц Вы из нее все удаляете, нагибая таким образом UNDO.
15 дек 11, 08:01    [11768502]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
alex-ls
для отката INSERT надо мало UNDO

А на изменение индексов оно не тратится?
15 дек 11, 09:02    [11768669]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6914
Сергей Арсеньев
alex-ls
для отката INSERT надо мало UNDO

А на изменение индексов оно не тратится?

а я про индексы ничего не писал, пусть человек код приведет или лог работы своего кода
15 дек 11, 09:21    [11768733]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Deng,

А заменить много insert на один, вроде:
insert into tt
select substr(to_char(tim,'hh:mi:ss'),1,7)||'0' "Время",avg(decode(nm,'a1',val)) a1,avg(decode(nm,'a2',val)) a2,avg(decode(nm,'a3',val)) a3,avg(decode(nm,'a4',val)) a4,avg(decode(nm,'a5',val)) a5,avg(decode(nm,'a6',val)) a6,avg(decode(nm,'a7',val)) a7,avg(decode(nm,'a8',val)) a8,avg(decode(nm,'a9',val)) a9,avg(decode(nm,'a10',val)) a10,avg(decode(nm,'a11',val)) a11,avg(decode(nm,'a12',val)) a12,avg(decode(nm,'a13',val)) a13,avg(decode(nm,'a14',val)) a14,avg(decode(nm,'a15',val)) a15,avg(decode(nm,'a16',val)) a16,avg(decode(nm,'a17',val)) a17,avg(decode(nm,'a18',val)) a18,avg(decode(nm,'a19',val)) a19,avg(decode(nm,'a20',val)) a20,avg(decode(nm,'a21',val)) a21,avg(decode(nm,'a22',val)) a22,avg(decode(nm,'a23',val)) a23,avg(decode(nm,'a24',val)) a24,avg(decode(nm,'a25',val)) a25,avg(decode(nm,'a26',val)) a26,avg(decode(nm,'a27',val)) a27,avg(decode(nm,'a28',val)) a28,avg(decode(nm,'a29',val)) a29,avg(decode(nm,'a30',val)) a30,avg(decode(nm,'a31',val)) a31,avg(decode(nm,'a32',val)) a32,avg(decode(nm,'a33',val)) a33,avg(decode(nm,'a34',val)) a34,avg(decode(nm,'a35',val)) a35,avg(decode(nm,'a36',val)) a36,avg(decode(nm,'a37',val)) a37,avg(decode(nm,'a38',val)) a38,avg(decode(nm,'a39',val)) a39,avg(decode(nm,'a40',val)) a40,avg(decode(nm,'a41',val)) a41,avg(decode(nm,'a42',val)) a42,avg(decode(nm,'a43',val)) a43,avg(decode(nm,'a44',val)) a44,avg(decode(nm,'a45',val)) a45,avg(decode(nm,'a46',val)) a46,avg(decode(nm,'a47',val)) a47,avg(decode(nm,'a48',val)) a48,avg(decode(nm,'a49',val)) a49,avg(decode(nm,'a50',val)) a50,avg(decode(nm,'a51',val)) a51,avg(decode(nm,'a52',val)) a52,avg(decode(nm,'a53',val)) a53,avg(decode(nm,'a54',val)) a54,avg(decode(nm,'a55',val)) a55,avg(decode(nm,'a56',val)) a56,avg(decode(nm,'a57',val)) a57,avg(decode(nm,'a58',val)) a58,avg(decode(nm,'a59',val)) a59,avg(decode(nm,'a60',val)) a60,avg(decode(nm,'a61',val)) a61,avg(decode(nm,'a62',val)) a62,avg(decode(nm,'a63',val)) a63,avg(decode(nm,'a64',val)) a64,avg(decode(nm,'a65',val)) a65,avg(decode(nm,'a66',val)) a66,avg(decode(nm,'a67',val)) a67,avg(decode(nm,'a68',val)) a68,avg(decode(nm,'a69',val)) a69,avg(decode(nm,'a70',val)) a70,avg(decode(nm,'a71',val)) a71,avg(decode(nm,'a72',val)) a72,avg(decode(nm,'a73',val)) a73,avg(decode(nm,'a74',val)) a74,avg(decode(nm,'a75',val)) a75,avg(decode(nm,'a76',val)) a76,avg(decode(nm,'a77',val)) a77,avg(decode(nm,'a78',val)) a78,avg(decode(nm,'a79',val)) a79,avg(decode(nm,'a80',val)) a80,avg(decode(nm,'a81',val)) a81,avg(decode(nm,'a82',val)) a82,avg(decode(nm,'a83',val)) a83,avg(decode(nm,'a84',val)) a84,avg(decode(nm,'a85',val)) a85,avg(decode(nm,'a86',val)) a86,avg(decode(nm,'a87',val)) a87,avg(decode(nm,'a88',val)) a88,avg(decode(nm,'a89',val)) a89,avg(decode(nm,'a90',val)) a90,avg(decode(nm,'a91',val)) a91,avg(decode(nm,'a92',val)) a92,avg(decode(nm,'a93',val)) a93,avg(decode(nm,'a94',val)) a94,avg(decode(nm,'a95',val)) a95,avg(decode(nm,'a96',val)) a96,avg(decode(nm,'a97',val)) a97,avg(decode(nm,'a98',val)) a98,avg(decode(nm,'a99',val)) a99,avg(decode(nm,'a100',val)) a100,avg(decode(nm,'a101',val)) a101,avg(decode(nm,'a102',val)) a102,avg(decode(nm,'a103',val)) a103,avg(decode(nm,'a104',val)) a104,avg(decode(nm,'a105',val)) a105,avg(decode(nm,'a106',val)) a106,avg(decode(nm,'a107',val)) a107,avg(decode(nm,'a108',val)) a108,avg(decode(nm,'a109',val)) a109,avg(decode(nm,'a110',val)) a110,avg(decode(nm,'a111',val)) a111,avg(decode(nm,'a112',val)) a112,avg(decode(nm,'a113',val)) a113,avg(decode(nm,'a114',val)) a114,avg(decode(nm,'a115',val)) a115,avg(decode(nm,'a116',val)) a116,avg(decode(nm,'a117',val)) a117,avg(decode(nm,'a118',val)) a118,avg(decode(nm,'a119',val)) a119,avg(decode(nm,'a120',val)) a120,avg(decode(nm,'a121',val)) a121,avg(decode(nm,'a122',val)) a122,avg(decode(nm,'a123',val)) a123,avg(decode(nm,'a124',val)) a124,avg(decode(nm,'a125',val)) a125,avg(decode(nm,'a126',val)) a126,avg(decode(nm,'a127',val)) a127,avg(decode(nm,'a128',val)) a128,avg(decode(nm,'a129',val)) a129,avg(decode(nm,'a130',val)) a130,avg(decode(nm,'a131',val)) a131,avg(decode(nm,'a132',val)) a132,avg(decode(nm,'a133',val)) a133,avg(decode(nm,'a134',val)) a134,avg(decode(nm,'a135',val)) a135,avg(decode(nm,'a136',val)) a136,avg(decode(nm,'a137',val)) a137,avg(decode(nm,'a138',val)) a138,avg(decode(nm,'a139',val)) a139,avg(decode(nm,'a140',val)) a140,avg(decode(nm,'a141',val)) a141,avg(decode(nm,'a142',val)) a142,avg(decode(nm,'a143',val)) a143,avg(decode(nm,'a144',val)) a144,avg(decode(nm,'a145',val)) a145,avg(decode(nm,'a146',val)) a146,avg(decode(nm,'a147',val)) a147,avg(decode(nm,'a148',val)) a148,avg(decode(nm,'a149',val)) a149,avg(decode(nm,'a150',val)) a150,avg(decode(nm,'a151',val)) a151,avg(decode(nm,'a152',val)) a152,avg(decode(nm,'a153',val)) a153,avg(decode(nm,'a154',val)) a154,avg(decode(nm,'a155',val)) a155,avg(decode(nm,'a156',val)) a156,avg(decode(nm,'a157',val)) a157,avg(decode(nm,'a158',val)) a158,avg(decode(nm,'a159',val)) a159,avg(decode(nm,'a160',val)) a160,avg(decode(nm,'a161',val)) a161,avg(decode(nm,'a162',val)) a162,avg(decode(nm,'a163',val)) a163,avg(decode(nm,'a164',val)) a164,avg(decode(nm,'a165',val)) a165,avg(decode(nm,'a166',val)) a166,avg(decode(nm,'a167',val)) a167,avg(decode(nm,'a168',val)) a168,avg(decode(nm,'a169',val)) a169,avg(decode(nm,'a170',val)) a170,avg(decode(nm,'a171',val)) a171,avg(decode(nm,'a172',val)) a172,avg(decode(nm,'a173',val)) a173,avg(decode(nm,'a174',val)) a174,avg(decode(nm,'a175',val)) a175,avg(decode(nm,'a176',val)) a176,avg(decode(nm,'a177',val)) a177,avg(decode(nm,'a178',val)) a178,avg(decode(nm,'a179',val)) a179,avg(decode(nm,'a180',val)) a180,avg(decode(nm,'a181',val)) a181,avg(decode(nm,'a182',val)) a182,avg(decode(nm,'a183',val)) a183,avg(decode(nm,'a184',val)) a184,avg(decode(nm,'a185',val)) a185,avg(decode(nm,'a186',val)) a186,avg(decode(nm,'a187',val)) a187,avg(decode(nm,'a188',val)) a188,avg(decode(nm,'a189',val)) a189,avg(decode(nm,'a190',val)) a190,avg(decode(nm,'a191',val)) a191,avg(decode(nm,'a192',val)) a192,avg(decode(nm,'a193',val)) a193,avg(decode(nm,'a194',val)) a194,avg(decode(nm,'a195',val)) a195,avg(decode(nm,'a196',val)) a196,avg(decode(nm,'a197',val)) a197,avg(decode(nm,'a198',val)) a198,avg(decode(nm,'a199',val)) a199,avg(decode(nm,'a200',val)) a200,avg(decode(nm,'a201',val)) a201,avg(decode(nm,'a202',val)) a202,avg(decode(nm,'a203',val)) a203,avg(decode(nm,'a204',val)) a204,avg(decode(nm,'a205',val)) a205,avg(decode(nm,'a206',val)) a206,avg(decode(nm,'a207',val)) a207,avg(decode(nm,'a208',val)) a208,avg(decode(nm,'a209',val)) a209,avg(decode(nm,'a210',val)) a210,avg(decode(nm,'a211',val)) a211,avg(decode(nm,'a212',val)) a212,avg(decode(nm,'a213',val)) a213,avg(decode(nm,'a214',val)) a214,avg(decode(nm,'a215',val)) a215,avg(decode(nm,'a216',val)) a216,avg(decode(nm,'a217',val)) a217,avg(decode(nm,'a218',val)) a218,avg(decode(nm,'a219',val)) a219,avg(decode(nm,'a220',val)) a220,avg(decode(nm,'a221',val)) a221,avg(decode(nm,'a222',val)) a222,avg(decode(nm,'a223',val)) a223,avg(decode(nm,'a224',val)) a224,avg(decode(nm,'a225',val)) a225,avg(decode(nm,'a226',val)) a226,avg(decode(nm,'a227',val)) a227,avg(decode(nm,'a228',val)) a228,avg(decode(nm,'a229',val)) a229,avg(decode(nm,'a230',val)) a230,avg(decode(nm,'a231',val)) a231,avg(decode(nm,'a232',val)) a232,avg(decode(nm,'a233',val)) a233,avg(decode(nm,'a234',val)) a234,avg(decode(nm,'a235',val)) a235,avg(decode(nm,'a236',val)) a236,avg(decode(nm,'a237',val)) a237,avg(decode(nm,'a238',val)) a238,avg(decode(nm,'a239',val)) a239,avg(decode(nm,'a240',val)) a240,avg(decode(nm,'a241',val)) a241,avg(decode(nm,'a242',val)) a242,avg(decode(nm,'a243',val)) a243,avg(decode(nm,'a244',val)) a244,avg(decode(nm,'a245',val)) a245,avg(decode(nm,'a246',val)) a246,avg(decode(nm,'a247',val)) a247,avg(decode(nm,'a248',val)) a248,avg(decode(nm,'a249',val)) a249,avg(decode(nm,'a250',val)) a250,avg(decode(nm,'a251',val)) a251,avg(decode(nm,'a252',val)) a252,avg(decode(nm,'a253',val)) a253,avg(decode(nm,'a254',val)) a254,avg(decode(nm,'a255',val)) a255,avg(decode(nm,'a256',val)) a256,avg(decode(nm,'a257',val)) a257,avg(decode(nm,'a258',val)) a258,avg(decode(nm,'a259',val)) a259,avg(decode(nm,'a260',val)) a260,avg(decode(nm,'a261',val)) a261,avg(decode(nm,'a262',val)) a262,avg(decode(nm,'a263',val)) a263,avg(decode(nm,'a264',val)) a264,avg(decode(nm,'a265',val)) a265,avg(decode(nm,'a266',val)) a266,avg(decode(nm,'a267',val)) a267,avg(decode(nm,'a268',val)) a268,avg(decode(nm,'a269',val)) a269,avg(decode(nm,'a270',val)) a270
 from gtt group by substr(to_char(tim,'hh:mi:ss'),1,7);

Нельзя?
15 дек 11, 11:32    [11769605]     Ответить | Цитировать Сообщить модератору
 Re: Запрос из MSSQL, транспонирование данных, вставка в Oracle, рост UNDO.  [new]
Deng
Member

Откуда:
Сообщений: 35
alex-ls
Сейчас прочитав Ваш текст, я думаю, что вместо временной таблицы у Вас обыкновенная таблица (просто Вы ее назвали временной) и раз в месяц Вы из нее все удаляете, нагибая таким образом UNDO.


Вставляю во временную таблицу. Скрипт таблицы:
CREATE GLOBAL TEMPORARY TABLE T_M_FL_TMP
(
  DATEANDTIME  DATE                             DEFAULT NULL,
  VAL          FLOAT(126)                       DEFAULT NULL,
  TAGNAME      VARCHAR2(255 CHAR)               DEFAULT Null
)
ON COMMIT DELETE ROWS
NOCACHE;
COMMENT ON COLUMN T_M_FL_TMP.DATEANDTIME IS 'Дата-время записи значения';
COMMENT ON COLUMN T_M_FL_TMP.VAL IS 'Числовое значение параметра';
COMMENT ON COLUMN T_M_FL_TMP.TAGNAME IS 'Имя параметра';
CREATE INDEX T_M_FL_TMP_IND1 ON T_M_FL_TMP
(DATEANDTIME);
CREATE INDEX T_M_FL_TMP_IND2 ON T_M_FL_TMP
(TAGNAME);


Код процедуры:
CREATE OR REPLACE PROCEDURE T_M_FL IS
    n NUMBER:=0;
    i NUMBER:=0;
    dt VARCHAR2(24);
    dt_in VARCHAR2(24);  
    TYPE MyArray IS VARRAY(222) OF REAL;-- тип массива  
    f_tbl MyArray;     

BEGIN   
    
    SELECT to_char(DT_INS,'yyyy-mm-dd hh24:mi:ss') INTO dt_in 
    FROM T_M_FL 
    WHERE SEQ=0;                 -- опорная дата-время
        
    INSERT INTO T_M_FL_TMP 
    (DATEANDTIME,VAL,TAGNAME) (
        SELECT d."DateAndTime",d."Val",f."TagName"        
        FROM "FlT_1s"@L1 d, "TagTable"@L1 f 
        WHERE d."TagIndex" = f."TagIndex"
        AND d."DateAndTime">= dt_in
    );
    
    f_tbl := MyArray();
    f_tbl.EXTEND(222);
    
    FOR r IN(        
        SELECT substr(TO_CHAR(a.DATEANDTIME, 'dd.mm.yyyy hh24:mi:ss'),1,18) dat, b.TAGINDEX TG, AVG(a.VAL) VAL 
        FROM T_M_FL_TMP a, S_TAGTABLE b
        WHERE DATEANDTIME <= (
            SELECT TO_DATE(SUBSTR(TO_CHAR(MAX(DATEANDTIME),'dd.mm.yyyy hh24:mi:ss'),1,18)||0,'dd.mm.yyyy hh24:mi:ss')
            FROM T_M_FL_TMP      
        )
        AND a.TAGNAME = b.TAGNAME
        GROUP BY substr(TO_CHAR(a.DATEANDTIME,'dd.mm.yyyy hh24:mi:ss'),1,18), b.TAGINDEX -- группировка по десяткам секунд
        ORDER BY 1,2

    )LOOP
        IF dt IS NULL THEN 
            dt := r.dat;
        END IF;
                
        IF dt <> r.dat THEN    -- делаем инсерт
           INSERT INTO T_M_FL (DT_INS,TAG0,TAG1,...,TAG221)
            VALUES (to_date(dt||0,'dd.mm.yyyyhh24:mi:ss'),f_tbl(1),f_tbl(2),...,f_tbl(222)                        
            );
            dt := r.dat;
            FOR i IN 1..222 LOOP
                f_tbl(i) := NULL;
            END LOOP;
            f_tbl(r.TG+1) := r.VAL;         --набираем массив
            n:=n+SQL%ROWCOUNT;-- количество обработанных
        ELSE             
            f_tbl(r.TG+1) := r.VAL;         --набираем массив
        END IF;
    END LOOP;         

-- если какие-либо изменения были сделаны, подтверждаем транзакцию
    IF n>0 THEN 
        UPDATE T_M_FL
        SET DT_INS = to_date(dt||0,'dd.mm.yyyy hh24:mi:ss')
        WHERE SEQ = 0;
    COMMIT;
    ELSE ROLLBACK; -- иначе - откатываем 
    END IF;
    
    EXCEPTION
        WHEN OTHERS THEN
        P_Log('P_M_FL', SQLERRM, SQLCODE);
        ROLLBACK;
END;
/




Вячеслав Любомудров
select tablespace_name, retention from dba_tablespaces where contents='UNDO'

Поле retention в таблице dba_tablespaces отсутствует. Есть поля:
TABLESPACE_NAME,
BLOCK_SIZE,
INITIAL_EXTENT,
NEXT_EXTENT,
MIN_EXTENTS,
MAX_EXTENTS,
PCT_INCREASE,
MIN_EXTLEN,
STATUS,
CONTENTS,
LOGGING,
FORCE_LOGGING,
EXTENT_MANAGEMENT,
ALLOCATION_TYPE,
PLUGGED_IN,
SEGMENT_SPACE_MANAGEMENT

Посмотрел таблицу V$UNDOSTAT. К сожалению, минимально доступная дата там составляет 8 декабря. 7 декабря у меня произошло переполнение UNDO.
Максимальное значение UNDOBLKS было
BEGIN_TIME	END_TIME	UNDOTSN	UNDOBLKS	TXNCOUNT	MAXQUERYLEN	MAXCONCURRENCY
12.09.2011 00:08:46	12.09.2011 00:18:46	11	100761	157383	24	2


На данный момент данные не сильно разнятся, приведу последние 5 строк
BEGIN_TIME	END_TIME	UNDOTSN	UNDOBLKS	TXNCOUNT	MAXQUERYLEN	MAXCONCURRENCY
12.15.2011 14:18:46	12.15.2011 14:24:14	11	24	523424	3	2
12.15.2011 14:08:46	12.15.2011 14:18:46	11	27	523280	3	1
12.15.2011 13:58:46	12.15.2011 14:08:46	11	30	522953	3	1
12.15.2011 13:48:46	12.15.2011 13:58:46	11	34	522707	3	3
12.15.2011 13:38:46	12.15.2011 13:48:46	11	99	522422	4	1
15 дек 11, 12:40    [11770241]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить