Force Oracle Drop Global Temp Table

Oracle globale midlertidige tabeller er ikke forbigående objekter. De er ordentlige bunkeborde. Vi opretter dem én gang og enhver session kan bruge dem til at gemme data, som kun er synlige for den session .

Det midlertidige aspekt er, at dataene ikke er vedvarende ud over en transaktion eller en session. Den vigtigste implementeringsdetalje er, at dataene skrives til et midlertidigt tablespace, ikke et permanent. Dataene skrives dog stadig til - og læses fra - disk, så der er en bemærkelsesværdig overhead til brugen af globale midlertidige tabeller.

Pointen er, at vi ikke skal droppe og genskabe midlertidige borde. Hvis du forsøger at porte SQL Server-logik til Oracle, bør du overveje at bruge PL/SQL-samlinger til at vedligeholde midlertidige data i hukommelsen. Find ud af mere.

Den specifikke årsag til ORA-14452 er, at vi ikke kan droppe en global midlertidig tabel, som har sessionsomfang persistens, hvis den har indeholdt data under sessionen. Selvom bordet i øjeblikket er tomt...

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>

Løsningen er at afslutte sessionen og oprette forbindelse igen, eller (lidt bizart) at afkorte tabellen og derefter droppe den.

SQL> truncate table gtt23;

Table truncated.

SQL> drop table gtt23;

Table dropped.

SQL>

Hvis en anden session bruger den globale midlertidige tabel - og det er muligt (deraf den globale nomenklatur), så vil du ikke være i stand til at droppe tabellen, før alle sessioner afbrydes.

Så den rigtige løsning er at lære at bruge globale midlertidige tabeller korrekt:Opret specifikke globale midlertidige tabeller, der matcher hver rapport. Eller, som jeg siger, brug PL/SQL-samlinger i stedet for. Eller endda bare lære at skrive velafstemt SQL. Ofte bruger vi midlertidige tabeller som en løsning på en dårligt skrevet forespørgsel, som kunne gemmes med en bedre adgangssti.

Når du har set på din fulde kode, virker strømmen endnu mere bizar:

Slip og genskab en global midlertidig tabel
Udfyld midlertidig tabel
Vælg fra midlertidig tabel til PL/SQL-array
Indsæt i den faktiske tabel ved hjælp af bulkinsert fra PL/SQL-array

Der er så meget overhead og spildt aktivitet herinde. Alt du skal gøre er at tage de data, du indsætter i v2d_temp og udfyld direkte vertical_design , ideelt set med en INSERT INTO ... SELECT * FROM-sætning. Du vil kræve noget forbehandling for at konvertere et JSON-array til en forespørgsel, men det er nemt at opnå i enten Java eller PL/SQL.

Det forekommer mig sikkert, at globale midlertidige tabeller ikke er den rigtige løsning til dit scenarie.

"vores chef eller andre personer bliver ved med at gøre noget på deres måde, så det kan du ikke ændre på"

Det, du har, er et Boss-problem ikke et programmeringsproblem . Derfor er det off-topic for så vidt angår StackOverflow. Men her er nogle forslag alligevel.

Det vigtigste at huske er, at vi ikke taler om et kompromis med en suboptimal arkitektur:Det, som din chef foreslår, vil ikke fungere. i et flerbrugermiljø. så dine muligheder er:

Ignorer ORA-14452 fejl, fortsæt i produktionen og brug derefter "men du fortalte mig at" forsvaret, når det hele går grueligt galt. Dette er det svageste spil.
Skriv skjult de globale tabeller og implementer noget, der vil fungere i et flerbruger-scenarie. Dette er højrisiko, fordi du ikke har noget forsvar, hvis du fejler implementeringen.
Tal med din chef. Fortæl dem, at du løber ind i ORA-14452 fejl, siger du har lavet nogle undersøgelser, og det ser ud til at være et grundlæggende problem med at bruge globale midlertidige tabeller på denne måde, men du har åbenbart overset noget. Spørg dem derefter, hvordan de kom uden om dette problem, når de har implementeret det før. Dette kan gå på flere måder, måske har de en løsning, måske vil de indse, at dette er den forkerte måde at bruge globale midlertidige tabeller på, måske vil de fortælle dig, at du skal fare vild. Uanset hvad, er dette den bedste tilgang:du har rejst bekymringer til det passende niveau.

Held og lykke.