Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 tmp table  [new]
grok
Member

Откуда:
Сообщений: 1686
что лучше ? -

create global temporary table xxx
(
...
)
on commit delete rows
/

... -- some code

commit;


или

create global temporary table xxx
(
...
)
on commit preserve rows
/

commit;

... -- some code

truncate table xxx;


в таблицу предполагается вставлять до 100 000 записей
12 май 11, 11:18    [10640129]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
Mumytroll
Member

Откуда:
Сообщений: 224
Встречный вопрос.
Вам данные во временной таблице нужны в течении сессии или в рамках одно транзакции?
12 май 11, 11:54    [10640473]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
Давид Тодуа
Member

Откуда:
Сообщений: 178
а может создать пакет, возвращающий таблицу?
12 май 11, 11:57    [10640493]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
Давид Тодуа
Member

Откуда:
Сообщений: 178
create or replace package body bbb is
function (....) return ggg pipelined is aaa nnn;
begin
for i in (select....)
begin
aaa.xxx:=890;
pipe row(aaa);
end loop;
end;

type nnn is record(xxx number);
type ggg is table of nnn;

ну как то так...
12 май 11, 12:02    [10640525]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
Viewer
Member

Откуда: Самара
Сообщений: 5369
grok
что лучше ? -

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4444273995237
If you NEED the rows to stay there, then you are not taking up more resources then necessary since you NEED THEM.

If you don't need the row to stay there for the session, but only for the transaction, then of course you would use on commit delete.

It is not a matter of resource utilization here, it is a simple matter of "what do you NEED"[/u]
12 май 11, 12:14    [10640610]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
grok
Member

Откуда:
Сообщений: 1686
Viewer
grok
что лучше ? -

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4444273995237
If you NEED the rows to stay there, then you are not taking up more resources then necessary since you NEED THEM.

If you don't need the row to stay there for the session, but only for the transaction, then of course you would use on commit delete.

It is not a matter of resource utilization here, it is a simple matter of "what do you NEED"[/u]


дело вот в чем
я могу организовать транзакции как хочу

например
могу

insert ...
update ...
update ...
commit;

а могу

insert ...
commit;
update ...
commit;
update ...
commit;

каких-то бизнес правил как организовать транзакции в данной задаче просто нет
надо собрать данные
произвести над ними некоторую обработку
затем вывести результат в отчет

вот и хотелось бы понять, как лучше ?

временные таблицы используются потому, что иначе запрос будет такого размера
что он уже будет просто почти неконтролируемым
(запрос, например, 800 строк это ничего так, да ?)
12 май 11, 12:37    [10640794]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
Viewer
Member

Откуда: Самара
Сообщений: 5369
"... а могу ..."
Issue Frequent COMMIT Statements
12 май 11, 12:47    [10640882]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
Viewer
Member

Откуда: Самара
Сообщений: 5369
P.S.
grok
commit;

... -- some code

truncate table xxx;

имхо, commit здесь избыточен, учитывая, что truncate является DDL командой ...
12 май 11, 12:51    [10640916]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
grok
Member

Откуда:
Сообщений: 1686
Viewer
"... а могу ..."
Issue Frequent COMMIT Statements


это не Frequent.
цикла нет
коммита всего 3.

каждый данный DML это до 100 000 записей
и надо думать, будет жрать немало UNDO
3 коммита уменьшили бы это в 3 раза

впрочем, не знаю
возможно, в этом смысла нет
а в том, чтобы жрать много UNDO нет ничего страшного
12 май 11, 13:01    [10640979]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
Viewer
Member

Откуда: Самара
Сообщений: 5369
Armed with this knowledge ... (c)
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:15826034070548
As you can see,
* The INSERT into the “real table generated a lot of redo. Almost no redo was generated for
the temporary table. This makes sense there is very little undo data generated for INSERTs and only
undo data is logged for temporary tables.
* The UPDATE of the real table generated about twice the amount of redo as the temporary
table. Again, this makes sense. About half of that UPDATE, the “before image, had to be saved. The
“after image (redo) for the temporary table did not have to be saved.
* The DELETEs took about the same amount of redo space. This makes sense, as the undo for a
DELETE is big, but the redo for the modified blocks is very small. Hence, a DELETE against a
temporary table takes place very much in the same fashion as a DELETE against a permanent table.
Note If you see the temporary table generating more redo than the permanent table with the
INSERT statement, you are observing a product issue in the database that is fixed in at least
Oracle 9.2.0.6 and 10.1.0.4 patch releases (the current shipping releases as of this writing).
Therefore, the following generalizations may be made regarding DML activity on temporary tables:
* An INSERT will generate little to no undo/redo activity.
* A DELETE will generate the same amount of redo as a normal table.
* An UPDATE of a temporary table will generate about half the redo of an UPDATE of a normal
table.

There are notable exceptions to the last statement. For example, if I UPDATE a column that is
entirely NULL with 2,000 bytes of data, there will be very little undo data generated. This UPDATE
will behave like the INSERT. On the other hand, if I UPDATE a column with 2,000 bytes of data to be
NULL, it will behave like the DELETE as far as redo generation is concerned. On average, you can
expect an UPDATE against a temporary table to produce about 50 percent of the undo/redo you would
experience with a real table.

In general, common sense prevails on the amount of redo created. If the operation you perform
causes undo data to be created, then determine how easy or hard it will be to reverse (undo) the
effect of your operation. If you INSERT 2,000 bytes, the reverse of this is easy. You simply go
back to no bytes. If you DELETE 2,000 bytes, the reverse is INSERTing 2,000 bytes. In this case,
the redo is substantial.

Armed with this knowledge, you will avoid deleting from temporary tables. You can use TRUNCATE,
bearing in mind, of course, that TRUNCATE is DDL that will commit your transaction, and in Oracle9i
and before invalidate your cursors, or just let the temporary tables empty themselves automatically
after a COMMIT or when your session terminated. All of these methods generate no undo and,
therefore, no redo. You will try to avoid updating a temporary table unless you really have to for
some reason. You will use temporary tables mostly as something to be INSERTed into and SELECTed
from. In this fashion, you’ll make optimum use of their unique ability to not generate redo.
12 май 11, 13:22    [10641123]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
alex-ls
Member

Откуда: Иркутская обл - Пенза - Москва
Сообщений: 6910
grok
временные таблицы используются потому, что иначе запрос будет такого размера
что он уже будет просто почти неконтролируемым
(запрос, например, 800 строк это ничего так, да ?)

Что-то плохо представляю себе такой запрос. И главная проблема озвучивается как просто большой текст, а скорость его выполнения будет нормальной? Хотя при кривой структуре БД все может быть...
12 май 11, 17:48    [10643495]     Ответить | Цитировать Сообщить модератору
 Re: tmp table  [new]
temp_tab
Guest
[quot grok]
Viewer
пропущено...
временные таблицы используются потому, что иначе запрос будет такого размера
что он уже будет просто почти неконтролируемым
(запрос, например, 800 строк это ничего так, да ?)


Сколько максимально пользователей одновременно будут работать с этой таблицей?
12 май 11, 17:55    [10643560]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить