Принудително намаляване на глобалната таблица на Oracle

Глобалните временни таблици на Oracle не са преходни обекти. Те са правилни купчини маси. Създаваме ги веднъж и всяка сесия може да ги използва за съхраняване на данни, които са видими само за тази сесия .

Временният аспект е, че данните не са постоянни след една транзакция или една сесия. Основната подробност за реализацията е, че данните се записват във временно пространство за таблици, а не в постоянно. Данните обаче все още се записват на диск и се четат от него, така че използването на глобални временни таблици има значителни разходи.

Въпросът е, че не трябва да пускаме и пресъздаваме временни таблици. Ако се опитвате да пренесете логиката на SQL Server в Oracle, тогава трябва да помислите за използването на PL/SQL колекции за поддържане на временни данни в паметта. Открийте повече.

Специфичната причина за ORA-14452 е, че не можем да изпуснем глобална временна таблица, която има постоянен обхват на сесията, ако съдържа данни по време на сесията. Дори ако таблицата в момента е празна...

SQL> create global temporary table gtt23 (col1 number)
  2  on commit preserve rows
  3  /

Table created.

SQL> insert into gtt23 values (1);

1 row created.

SQL> commit;

Commit complete.

SQL> delete from gtt23;

1 row deleted.

SQL> commit;

Commit complete.

SQL> drop table gtt23;
drop table gtt23
           *
ERROR at line 1:
ORA-14452: attempt to create, alter or drop an index on temporary table already in use

SQL>

Решението е да прекратите сесията и да се свържете отново или (донякъде странно) да съкратите таблицата и след това да я пуснете.

SQL> truncate table gtt23;

Table truncated.

SQL> drop table gtt23;

Table dropped.

SQL> 

Ако някоя друга сесия използва глобалната временна таблица - и това е възможно (следователно глобалната номенклатура), тогава няма да можете да пуснете таблицата, докато всички сесии не бъдат прекъснати.

Така че истинското решение е да се научите да използвате правилно глобалните временни таблици:създайте специфични глобални временни таблици, които да съответстват на всеки отчет. Или, както казах, използвайте вместо това колекции PL/SQL. Или дори просто се научете да пишете добре настроен SQL. Често използваме временни таблици като решение за лошо написана заявка, която може да бъде запазена с по-добър път за достъп.

След като разгледахме пълния ви код, потокът изглежда още по-странен:

1. Хвърлете и създайте отново глобална временна таблица
2. Попълване на временна таблица
3. Изберете от временна таблица в PL/SQL масив
4. Вмъкнете в действителната таблица, като използвате групово вмъкване от PL/SQL масив

Тук има толкова много режийни и пропилени дейности. Всичко, което трябва да направите, е да вземете данните, които вмъквате в v2d_temp и директно попълнете vertical_design , в идеалния случай с израз INSERT INTO ... SELECT * FROM. Ще ви е необходима известна предварителна обработка, за да конвертирате JSON масив в заявка, но това е лесно за постигане или в Java, или в PL/SQL.

Струва ми се сигурно, че глобалните временни таблици не са правилното решение за вашия сценарий.

„нашият шеф или други хора продължават да правят нещо по своя начин, така че не можете да промените това“

Това, което имате, е проблем с шефа не е проблем с програмирането . Следователно това не е по темата, що се отнася до StackOverflow. Но все пак ето някои предложения.

Основното нещо, което трябва да запомните, е, че не говорим за компромис с някаква неоптимална архитектура:това, което вашият шеф предлага, очевидно няма да работи в многопотребителска среда. така че вашите опции са:

1. Игнорирайте ORA-14452 грешка, продължете с производството и след това използвайте защитата "но ти ми каза да", когато всичко се обърка ужасно. Това е най-слабата игра.
2. Скрито изхвърляйте глобалните таблици и внедрявайте нещо, което ще работи в сценарий с много потребители. Това е висок риск, защото нямате защита, ако нарушите изпълнението.
3. Говорете с шефа си. Кажете им, че се сблъсквате с ORA-14452 грешка, кажете, че сте направили някакво разследване и изглежда фундаментален проблем с използването на глобални временни таблици по този начин, но очевидно сте пропуснали нещо. След това ги попитайте как са заобиколили този проблем, когато са го прилагали преди. Това може да върви по няколко начина, може би те имат заобиколно решение, може би ще разберат, че това е грешен начин за използване на глобални временни таблици, може би ще ви кажат да се изгубите. Така или иначе, това е най-добрият подход:повдигнахте опасенията си до подходящото ниво.

Успех.