I need to create a table every morning based on overnight generated data from a massive table. This will then be accessed by a handful of users form Excel.
My initial approach was to use a materilazed view and when this was rejected (for political reasons) to used Managed XLL but this was rejected for other reasons. I don't want to get messed up with Temporary tables and so really just need to know how to schedule an Oracle Create Table statement as our DBA says it can't be done.
My faith in SO users sasy otherwise though!
I don't see why you have to create a new table every morning and not use an existing one?
This creates your table from PL/SQL. Is this what you want?
CREATE OR REPLACE PROCEDURE make_table AS
BEGIN
EXECUTE IMMEDIATE 'CREATE TABLE your_table ( column_1 INT PRIMARY KEY, column_2 VARCHAR2(10) )';
END make_table;
/
EXEC make_table;
Your user needs to have the necessary grants, grants given by role don't apply to compiled PL/SQL code.
Related
Probably I ask for the impossible, but I'll ask anyway.
Is there an easy way to select from one Oracle session and then insert/commit into another?
(I guess, technically it could be done with pl/sql procedure calls and PRAGMA AUTONOMUS Transactions, but it would be a hassle)
I have the following scenario:
I run some heavy calculations and update / insert into some tables.
After the process is completed I would like to 'backup' the results
(create table as select or insert into another temp table) and then rollback my current session without loosing the backups.
Here is desired/expected behavior:
Oracle 11g
insert into TableA (A,B,C) values (1,2,3);
select * from TableA
Result: 1,2,3
create table [in another session] TempA
as select * from TableA [in this session];
rollback;
select * from TableA;
Result null
select * from TempA;
Result 1,2,3
Is this possible?
Is there an easy way to select from one Oracle session and then insert/commit into another?
Create a program in a third-party language (C++, Java, PHP, etc.) that opens two connections to the database; they will have different sessions regardless of whether you connect as different users or both the same user. Read from one connection and write to the other connection.
you can insert your "heavy calculation" into a Oracle temp Table .
CREATE GLOBAL TEMPORARY TABLE HeavyCalc (
id NUMBER,
description VARCHAR2(20)
)
ON COMMIT DELETE ROWS;
the trick is that when you commit the transaction all rows are deleted from temporary table.
Then you first insert data into the temp table, copy the result to you backup table and commit the transaction.
The oracle documentation here:
https://docs.oracle.com/en/database/oracle/oracle-database/21/spatl/indexing-querying-spatial-data.html#GUID-8E6AE949-758B-4A5E-9453-CC3D00647497
Talks about creating an index in schema A with user B
CREATE INDEX t1_spatial_idx on A.T1(geometry) INDEXTYPE IS mdsys.spatial_index_v2;
This, however, requires you to insert into user_sdo_geom_metadata. I'm trying to do this as one single connected user and that seems impossible. Let's say I'm user B, whenever I insert into user_sdo_geom_metadata the resulting changes won't get picked up by the view that the CREATE INDEX statement uses, which is ALL_SDO_GEMO_METADATA. As an example try:
INSERT INTO user_sdo_geom_metadata (table_name,column_name,diminfo,srid) VALUES
('T1','geometry', sdo_dim_array(sdo_dim_element('X',-180.0,180.0, 0.005),sdo_dim_element('Y',-90.0,90.0, 0.005)), 4326);
There is no way to specify the schema to get this into the correct format. In fact, if the T1 table here doesn't exist in your schema then nothing appears in ALL_SDO_GEMO_METADATA. I've tried
ALTER SESSION SET CURRENT_SCHEMA = 'A'
But that doesn't work. I'm trying to use Schemas as a way of collating together self-contained groupings of tables, views, indexes, etc. like you would in a normal database. In other words, I'm trying to use them like actual schemas. Oracle makes this challenging at the best of times, and I don't want to manage separate logins for each schema, but I can't see how it's possible to do this for spatial indexes.
Well, this was an epic struggle but got there in the end. The only way to create the metadata AND the index as another user is to create a stored procedure that does the INSERT but it's not as easy as just following the instructions, you have to call the package proc directly like so:
CREATE OR REPLACE PROCEDURE "<user name>".ADDMETADATA(
schema_name VARCHAR2, table_name VARCHAR2, column_name VARCHAR2, srid NUMBER, bounds MDSYS.SDO_DIM_ARRAY)
IS
BEGIN
mdsys.sdo_meta.insert_all_sdo_geom_metadata(schema_name, table_name, column_name, bounds, srid);
END ADDMETADATA;
Which almost certainly isn't supported but the standard way is broken so you have to. You then need to create this in every single new schema along with giving the schema user CREATE TABLE and CREATE SEQUENCE permissions. So to create a schema programmatically and have it all work boils down to the following steps:
CREATE the Schema/User and set the tablespace
GRANT CREATE SEQUENCE to the Schema/User
GRANT CREATE TABLE to the Schema/User
ALTER the quota on the TABLESPACE for the Schema/User
CREATE the stored proc above
CALL the stored proc
CALL create INDEX
Painfully long-winded but works. The whole schema-as-user thing remains a terrible idea, most databases can do all this with one SQL statement.
I have just created a new read only user (TEMPDBREAD) for our developers # our oracle Database 11.2.0.4
Now they like read access to all tables from just one schema (TEMPDBUSER)
is there an alternative to grant select any table.
They should not be able to read the other schemes. But since the table structure often changes, it is difficult to justify everything manually.
That's why select any table is awarded very quickly and easier to place
Can i deny the access to the other schemes anyway?
Any Idea how i can solve this very simple?
BR Julian
Grant Table Access manually
Grant Select ANY Table
Nope. You either give them select any table and let them read any table in the database or you give them access to each table in TempDBUser individually. In the vast, vast majority of cases, you'd want to give them access to each table in TempDBUser (presumably via a role because there will be many developer accounts that need to run queries).
It isn't clear to me why giving object-level access is problematic for you. "Table structure changes" do not require new grants since they're just changes to existing objects. If you really mean that new tables are created frequently, you'd just want to incorporate the grants into your change control and deployment process.
If you have a packaged application that creates new tables periodically (a terrible practice), you could create a DDL trigger that issued the grant every time a new table was created in TempDBUser. You'd need a DDL trigger that submitted a job via the dbms_job package that did the actual grant which is a rather convoluted architecture but it works.
spool /tmp/grant_issue.sql
select 'grant select on TEMPDBUSER.' || table_name || ' TO TEMPDBREAD;' from dba_tables where owner='TEMPDBUSER' ;
spool off;
run the spool file.
sqlplus #/tmp/grant_issue.sql
We wish to create an ANALYTICS role on our Oracle database. Anyone in this ANALYTICS role should be able to SELECT across any views in one (or more) schemas, but not ALL schemas.
We have a schema called ARIEL for example, and when we create new tables and views, we don't want to have to constantly apply GRANTS to the ANALYTICS role, and so we are hoping there is a way to apply a grant like this "GRANT SELECT ON ALL TABLES IN SCHEMA_X TO ANALYTICS"...note ANALYTICS is a role, not a schema.
Our DBA is saying this is not possible, and any future objects we create will need to have a grant applied, giving access to the ROLE.
"Our DBA is saying this is not possible, and any future objects we create will need to have a grant applied, giving access to the ROLE."
Your DBA is correct. You are searching for schema wide privileges(not implemented yet).
More: GRANT SELECT on all tables in a schema
Your DBA is correct that there would need to be a grant for every object that is created. It is possible to automate this which gives you basically the behavior that you want. I've done this in the past. But I'd seriously question the requirement before implementing it.
In general, new tables aren't created in production automatically, they're created as part of a build process. Part of that build process involves doing things like figuring out who should have access to the tables. Assuming that you're going through some sort of source control system, that means that you've got a history of the grants on objects and you can tie back changes in those grants to user stories. That's a useful thing to have.
If you have applications that are creating new tables in production dynamically (like an off the shelf app I was supporting) or doing something else where giving grants as part of a build process would be problematic, you can automate the process with a DDL trigger.
Create a DDL trigger that fires when a table is created
In that DDL trigger, use dbms_job to run a grant statement immediately after the CREATE TABLE statement commits
Something like this should work (untested)
CREATE OR REPLACE TRIGGER ddl_create
AFTER CREATE ON SCHEMA
DECLARE
l_job BINARY_INTEGER;
l_sql VARCHAR2(4000);
BEGIN
IF ora_dict_obj_type = 'TABLE'
THEN
l_sql := 'grant select on ' ||
ora_dict_obj_owner || '.' || ora_dict_obj_name ||
' to analytics';
DBMS_JOB.SUBMIT (
job => l_job,
what => l_sql );
END IF;
END;
Since the job runs asynchronously, it is possible that it will take a second or two to run after the table is created which may be an issue if the application immediately tries to run a query on the object. It is also possible that your DBA may disable jobs or limit the number of jobs that can run simultaneously which could further delay the grant. And if something goes wrong with the trigger or the job, this is a sufficiently obscure approach that it is going to take people a while to figure out where the problem is. DBAs aren't in the habit of looking for DDL triggers that may be granting privileges when someone decides, say, that they want a new role to automatically get insert access on the new table or when a grant didn't happen because jobs were disabled.
I am searching for a way, to store only the tables and columns that are added in the database with the one who created it (nachine_name) in a log table.
I tried to add a trigger on sys table user_tab_cols but I cannot do that Why cannot I create triggers on objects owned by SYS?
The system table user_objects will give me the date when a table created, but I want also to know which machine created it. and I also want to track the column creation and modification and log them in a table.
Is that possible ? is there a way for that ?
you can create a database event trigger:
CREATE OR REPLACE TRIGGER log_ddl_event_trg
AFTER DDL
ON DATABASE
DECLARE
v_sql_list ora_name_list_t;
v_sql_txt VARCHAR2(2500);
BEGIN
FOR i in 1..ORA_SQL_TXT(v_sql_list) LOOP
v_sql_txt := v_sql_txt || v_sql_list(i);
EXIT WHEN length(v_sql_txt ) >= 2000;
END LOOP;
...
END;
/
in the Trigger, you can get the executed ddl-statement using the ORA_SQL_TXT() Funktion, and then log it in the table together with the other data (log_date, user etc.).