I have a GTT in my oracle apex application.
CREATE GLOBAL TEMPORARY TABLE "SEARCH"
( "CODE" VARCHAR2(15 BYTE),
"HEAD" VARCHAR2(100 BYTE),
"BRCODE" VARCHAR2(3 BYTE)
) ON COMMIT PRESERVE ROWS ;
But the GTT preserves it's rows even after the user log out from the application. If another user login to the application, he can access the same data created by the previous user. What might be the problem with GTT or session ?
Please read this answer thread from oracle community. GTT - Global Temporary Table - Problem with Apex
Related
Good morning,
I allready know how to do oracle backups with expdp and impdp. It is also no problem for me to remap backups from one schema to an other.
But know I have something where I find no solution to solve it.
I have a table with an ID column. This column has a default value based on a sequence.
CREATE TABLE "TABLE_NAME"
( "ID" NUMBER(*,0) DEFAULT "TABLE_NAME_ID_SEQ"."NEXTVAL",
"KEY" VARCHAR2(200 BYTE),
"VALUE" CLOB
)
After executing thise statement Oracle defines this default with "MY_USER"."TABLE_NAME_ID_SEQ"."NEXTVAL".
This is not an issue until I try to uses the backup with a different schema name. The REMAP_SCHEMA parameter of impdp seems only to change the schema definition in the tabelnames but not in the default values. So the imported backup creates a table with a default values which references to a wrong schema.
How could I solve this?
Best regards"
I am going to develop a reporting database by querying the production database once using a stored procedure.
The stored procedure will then write the result into it's own output tables.
Following is the schema for the output table:
Create table Output (
Customer_ID NUMBER(15) not null,
STD_HASH RAW(1000 BYTE) ,
VALID_PERIOD_START NOT NULL TIMESTAMP(6),
VALID_PERIOD_END NOT NULL TIMESTAMP(6),
Address VARCHAR2(30 CHAR),
period for valid_period(valid_period_start,valid_period_end),
Constraint Output_PK Primary Key ( Customer_ID, valid_period_start, valid_period_end )
)
As the stored procedure will perform a lot of update and delete statement on the output table, and those output table is very big. The largest one I have right now is 8GB. I am thinking to alter those output tables with the "SHRINK SPACE" option at the end of the stored procedure to reclaim some spaces.
Following is the statement that I am going to apply:
Alter table OUTPUT1 ENABLE ROW MOVEMENT; -- Temporary enable row movement for the table
Alter TABLE output2 SHRINK SPACE;
Alter table OUTPUT1 DISABLE ROW MOVEMENT;-- Disable row movement.
Those output tables are temporal table that is using the valid period and the ID from production as a primary key.
However, as I am very new with the Shrink Space function. Can anyone tell me what is the disadvantage of using this function?
The table, basically will not be updated from anywhere other than this stored procedure. The stored procedure will be scheduled to run in a daily base.
Thanks in advance!
yes, shrink has some restrictions:
(1) it locks the table during the shrink operation
(2) it change the rowid of the table.
(3) it needs the tablespace with automatic segment-space management enabled.
we have other alternatives to claim the unused space:
(1) export/import
(2) dbms_redefinition
I'm trying to declare local temporary table using the example from Oracle / PLSQL: LOCAL TEMPORARY TABLES. But when I try to insert it into sqlplus' CLI and hit Enter, it does not execute anything and I don't know what to do next to complete the command except pressing Ctrl+C interrupting command inputing:
SQL> DECLARE LOCAL TEMPORARY TABLE suppliers_temp
( supplier_id number(10) NOT NULL,
supplier_name varchar2(50) NOT NULL,
contact_name varchar2(50)
); 2 3 4 5
6
7 ;
8 ^C
To execute this query I've logged in as SYSTEM user.
Why this example does not work for me?
local temporary tables aren't a thing in the Oracle RDBMS. Instead, you can have a Global Temporary Table (GTT) (which creates a permanent table, but the data is held at session level) or, introduced in 18c, you can have a Private Temporary Table (PTT) (the table definition and data are held at session level).
Both are similar to the standard create table statement, so to create a GTT that drops the rows when you commit, you would do something like:
create global temporary table table_name (col1 number, col2 varchar2(20))
on commit delete rows;
I want to create on commit materialized oracle view pointing to table from different schema within same database instance.
schema (BATCH):
CREATE TABLE "BATCH"."BATCH_CONFIG"
( "KEY" VARCHAR2(100 BYTE),
"VALUE" VARCHAR2(4000 BYTE),
"COMMENTS" VARCHAR2(4000 BYTE),
"UPDATED_BY" VARCHAR2(25 BYTE),
"UPDATED" TIMESTAMP (6),
CONSTRAINT "PK_BATCH_CONFIG" PRIMARY KEY ("KEY")
);
create materialized view log on batch_config;
grant all on batch_config to profile;
schema (PROFILE):
create materialized view mv_batch_config REFRESH FAST ON COMMIT
as select * from BATCH.batch_config;
Got Error:
SQL Error: ORA-12018: following error encountered during code generation for "PROFILE"."MV_BATCH_CONFIG"
ORA-00942: table or view does not exist
12018. 0000 - "following error encountered during code generation for \"%s\".\"%s\""
*Cause: The refresh operations for the indicated materialized view could
not be regenerated due to errors.
*Action: Correct the problem indicated in the following error messages and
repeat the operation.
What is the issue with ? I am able to view query by (from profile schema) select * from BATCH.batch_config
OK finally I got the solution.
I have to grant select on mview log also.
GRANT SELECT ON MLOG$_BATCH_CONFIG TO PROFILE;
I am a SQL guy, but am doing a stint in ORACLE land. Nothing wrong w/ expanding one's boundaries....
I have been given a view to a table. I do have permission to delete from that view.
Delete from vwGregsViewOnTable where SEQ = 12345
this takes 12 minutes. There are ~20M rows in the table, but 12 minutes?
I got a DBA involved and they confirmed that I am doing a table scan.
We scripted the table and that follows here in part...
CREATE TABLE SYT_SYALERTQUEUE
(
IDRECMAIN VARCHAR2(32 BYTE),
IDRECPARENT VARCHAR2(32 BYTE),
IDREC VARCHAR2(32 BYTE),
SEQ NUMBER(10),
.
.
.
CREATE INDEX SYNDX00000000000000000002277 ON SYT_SYALERTQUEUE
(SEQ)
LOGGING
TABLESPACE WV90NDX
It does appear that there is an index on the column I was told I should use.
in this case, vwGregsViewOnTable is the view on SYT_SYALERTQUEUE
My question is - how can I coax ORACLE into using the index. It doesnt seem to want to by default.
To answer your question: You can force the Oracle's SQL-optimizer to use a certain index:
SELECT /*+ INDEX (table indexname)*/ col1, col2
FROM table
WHERE blabla ;
This thingie here /*+ INDEX (table indexname)*/ is called an optimizer-hint. Most of the time its not really wise to use that.