last_ddl_time in dba_objects table Oracle - oracle

what does column "last_ddl_time" in table "dba_objects" really mean? what causes the change of the date in this column?
We are testing this as part of change management in Oracle and im not sure what this column really represents.
Thank you in advance!
regards

According to the docs:
Timestamp for the last modification of the object resulting from a DDL
statement (including grants and revokes)
So creating a table, altering a table, rebuilding an index, granting access and so on and so forth, depending on the object type.
Did you have a more specific question, or was that it?

Related

how to fetch last access TIMESTAMP of a table in oracle?

How to fetch the last access date for a table in oracle using the query from Oracle DB?
I am using select TIMESTAMP from dba_tab_modifications query it's giving me last updates in table
but I need last execution of select query statement on a particular table
Thanks in Advance
Sai Kumar
Oracle does not keep this information by default. You need to enable the appropriate AUDIT rules. But I'd question what problem you think this will solve. Auditing every access to a table will be a lot of audit records.

Oracle APEX automatic column add/remove in region

I have made a view that changes it's columns frequently with dynamic SQL. I use a pivot to make rows into columns. I display the view in an interactive grid. The SQL query that is executed:
select * from <DB>.<VIEWNAME>.
On refresh it updates the ROWS in the grid, but not the COLUMNS. The select * does not take column changes into account, BUT if I alter the SQL query by adding a space ( or any other thing in the query) and then saving the page in the page designer, the columns sync up to the view.
Does someone know a good solution to my problem? Where can I find the procedure that executes this refresh? If I know where it is I can possiby use it after the insertion of a column (or delete / update). Any tips? Warning, I am a total novice in oracle apex and sql developer.
Thanks in advance!
This is the wrong way to go about this. In Apex, and in Oracle in general, columns are determined when the query is parsed. If you change the underlying structure, your query has to be reparsed and only then do the columns change.
Think about it. If the first column in your result set was a DATE and you had your Apex column attributes set up to format and display that data, then your query changed to a NUMBER, its not clear what would happen.
What you probably want to do is create your region based on a function that returns a sql query as a VARCHAR2. (I think you can do this in 18.x; I'm still mostly using 5.2.) Your function gets parsed when the region is displayed. You can even use another function to return a colon-separated list of column headers if the names are dynamic.

Best way to add column with default value while under load

When adding a column to a table that has a default value and a constraint of not null. Is it better to run as a single statement or to break it into steps while the database is under load.
ALTER TABLE user ADD country VARCHAR2(4) DEFAULT 'GB' NOT NULL
VERSUS
ALTER TABLE user ADD country VARCHAR2(2)
UPDATE user SET country = 'GB'
COMMIT
ALTER TABLE user MODIFY country DEFAULT 'GB' NOT NULL
Performance depends on the Oracle version you use. Locks are generated anyway.
If version <= Oracle 11.1 then #1 does the same as #2. It is slow anyway.
Beginning with Oracle 11.2, Oracle introduced a great optimization for the first statement (one command doing it all). You don't need to change the command - Oracle just behaves differently. It stores the default value only in data dictionary instead of updating each physical row.
But I also have to say, that I encountered some bugs in the past related to this feature (in Oracle 11.2.0.1)
failure of traditional import if export was done with direct=Y
merge statement can throw an ORA-600 [13013] (internal oracle error)
a performance problem in queries using such tables
I think this issues are fixed in current version 11.2.0.3, so I can recommend to use this feature.
Some time ago we have evaluated possible solutions of the same problem. On our project we had to remove all indexes on table, perform altering and restore indexes back.
If your system needs to be using the table then DBMS_Redefinition is really your only choice.

ORACLE :Are grants removed when an object is dropped?

I currently have 2 schemas, A and B.
B has a table, and A executes selects inserts and updates on it.
In our sql scripts, we have granted permissions to A so it can complete its tasks.
grant select on B.thetable to A
etc,etc
Now, table 'thetable' is dropped and another table is renamed to B at least once a day.
rename someothertable to thetable
After doing this, we get an error when A executes a select on B.thetable.
ORA-00942: table or view does not exist
Is it possible that after executing the drop + rename operations, grants are lost as well?
Do we have to assign permissions once again ?
update
someothertable has no grants.
update2
The daily process that inserts data into 'thetable' executes a commit every N insertions, so were not able to execute any rollback. That's why we use 2 tables.
Thanks in advance
Yes, once you drop the table, the grant is also dropped.
You could try to create a VIEW selecting from thetable and granting SELECT on that.
Your strategy of dropping a table regularly does not sound quite right to me though. Why do you have to do this?
EDIT
There are better ways than dropping the table every day.
Add another column to thetable that states if the row is valid.
Put an index on that column (or extend your existing index that you use to select from that table).
Add another condition to your queries to only consider "valid" rows or create a view to handle that.
When importing data, set the new rows to "new". Once the import is done, you can delete all "valid" rows and set the "new" rows to "valid" in a single transaction.
If the import fails, you can just rollback your transaction.
Perhaps the process that renames the table should also execute a procedure that does your grants for you? You could even get fancy and query the dictionary for existing grants and apply those to the renamed table.
No :
"Oracle Database automatically transfers integrity constraints, indexes, and grants on the old object to the new object."
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_9019.htm#SQLRF01608
You must have another problem
Another approach would be to use a temporary table for the work you're doing. After all, it sounds like it is just the data is transitory, at least in that table, and you wouldn't keep having to reapply the grants each time you had a new set of data/create the new table

Can I detect the version of a table's DDL in Oracle?

In Informix, I can do a select from the systables table, and can investigate its version column to see what numeric version a given table has. This column is incremented with every DDL statement that affects the given table. This means I have the ability to see whether a table's structure has changed since the last time I connected.
Is there a similar way to do this in Oracle?
Not really. The Oracle DBA/ALL/USER_OBJECTS view has a LAST_DDL_TIME column, but it is affected by operations other than structure changes.
You can do that (and more) with a DDL trigger that keeps track of changes to tables. There's an interesting article with example here.
If you really want to do so, you'd have to use Oracle's auditing functions to audit the changes. It could be as simple as:
AUDIT ALTER TABLE WHENEVER SUCCESSFUL on [schema I care about];
That would at least capture the successfuly changes, ignoring drops and creates. Unfortunately, unwinding the stack of the table's historical strucuture by mining the audit trail is left as an exercise to the reader in Oracle, or to licensing the Change Management Pack.
You could also roll your own auditing by writing system-event triggers which are invoked on DDL statements. You'd end up having to write your own SQL parser if you really wantedto see what was changing.

Resources