I have a question about transactional queries on oracle Db(or other RDBMS).
I have for instance 3 tables in my transactionnal script. What happen if I call begin transaction on each of three tables and at the end I command commit also on each table?
Is it necessary to do that?
Related
I've a job which runs with multiple instances i.e. the code base for all instances is same, but each instance works on set of data allocated to it so as to achieve parallelism and better throughput for the application.
These jobs use global temporary table for working through the data as there are multiple complex operations performed before final output is computed.
In case of failure, the transaction is rolled back (as it should), but with this I'm also losing the data in gtt.
Is there a way that the records in gtt can be copied over to another permanent table while rolling back the transaction.
I know it sounds weird, but this is a practical problem I'm facing.
I need to somehow store data in session table in case of failure of any sql, while rolling back the transaction as one of the sql has failed.
Thanks.
Hm, maybe something like this:
create a permanent table which will hold GTT data in case of failure
create an autonomous transaction procedure which would insert into permanent select * from gtt and commit
in exception handler section call that procedure and then rollback
The only way is printing the required data before your rollback.
You can use UTL_FILE to store data in the file. Later, you can use external table concept of oracle to retrieve data in the table.
Cheers!!
What will happen in the backend when we execute a SQL Statement in an Oracle Database?
There are different process for both DDL and DML. For example DML reads data to the buffer cache and once commit is issued, it will only then update to DB.
Likewise i need to know the entire back end process when a query executed in oracle.
Please explain for both DDL and DML.
I am having table ABC and using in procedures with Delete action at starting and select action at end. (Delete with no where clause)
Now if a process A invokes the procedure and it is at select on table ABC, then at same time another process B invokes the procedure which reached to Delete on ABC without any where clause.
So my question is, would process A can find the data as Delete with no where clause is happening at same time.
Literally, is synchronization would be there among tables.
I'd suggest you read about Oracle multi-versioning and ACID transactions
http://docs.oracle.com/cd/E18283_01/server.112/e16508/consist.htm
https://en.wikipedia.org/?title=ACID
Things that happen in a session within a transaction are not available to another session. This continues until a commit is issued. You have your own version until a commit or rollback is issued.
Oracle starts a transaction by default unlike some other database servers. Other database servers also have their own defaults and different implementations of ACID.
I am keeping two passwords (actually the same password as far as website human user knows,but hashed and salted using two different algorithms and salts) for my website. One is place in WebUsers table and that is where password is verified when users login at website. The other is password of an oracle user, each website user corresponds to an oracle user.
When making change password procedure, I have to change password in WebUsers table as well as in oracle, in a transaction. The problem is, the DDL statement [alter user ...] commit before performing any action. If [alter user ...] fail and in the exception handling code I rollback the transaction, the changes in the WebUsers table are not rollbacked. Is there some work around?
There is just no way to have a DML and DDL in one atomic transaction under Oracle.
In Oracle a a DDL will always explicitly result in a commit before running the DDL.
Typically in these sort of scenarios, you should execute the step that's most likely to fail first, i.e. in your case the DDL 'Alter User'.
And then run your DML , only if the DDL succeeds , but then again, there is this issue of the DML failing, and then not being able to rollback the DDL, at which point you'll simply have to run another DDL to revert the changes made by the first DDL.
The idea is that the second step is far more likely to fail than the first step.
This pattern is also used, where you've to deal with say something like JMS + JDBC , and you can't use a JTA transaction to wrap the JMS + JDBC activities in a single transcation.
Could in Oracle DDL (create/alter) be transactional like they are in MS SQL (started from 2005)?
DDL is not transactional in Oracle. From the 11.2 doc:
Oracle Database implicitly commits the current transaction before and after every DDL statement.
No. In Oracle DDL statements themselves are not transactional.
Running a DDL statement will implicitly commit any open transaction for that session before starting the actual work.
In addition some statements, like an alter table statement, may fail if another session has an open transaction on the object being modified or one of its dependencies. You can set a ddl_lock_timeout to specify how long you want Oracle to wait for the object to become available.
See DDL Statements for a summary of types of DDL statements and information about their behaviour regarding locks and transactions.
Oracle Database implicitly commits the current transaction before and after every DDL statement.
Just discovered this, so needs more investigation, but Oracle's create schema authorization at least allows to bundle several DDL statements in a single transaction, thus avoiding several commits, and guarantees no side-effects, i.e. a rollback, if any one of the DDL statement fails.
It is unclear whether the rollback applies to the wrapped DDL statements only, as-if the create schema started a save-point, or the outer transaction with possibly some prior DML statement.
You still cannot avoid the commit after the last wrapped DDL statement complete successfully though.