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.
Related
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?
I am finding a resolution to record DML and DDL changes made to specified Oracle schemas or tables dynamically, which meaning that schemas and tables monitored can be changed in application run time.
In a word, I am going to achieve an Oracle database probe, not for synchronizing databases.
Updated
For example, I set a monitor to a table test for database db. I want to retrieve all changes made to test, such as drop/add/modify a column or insert/update/delete records and so on, I need to analyze and send all changes to a blockchain such as table test added a column field1,that's why I want to get all executed SQL for the monitored tables.
I have read Oracle docs about data guard and streams.
Data guard doc says:
SQL Apply (logical standby databases only)
Reconstitutes SQL statements from the redo received from the primary database and executes the SQL statements against the logical standby database.
Logical standby databases can be opened in read/write mode, but the target tables being maintained by the logical standby database are opened in read-only mode for reporting purposes (providing the database guard was set appropriately). SQL Apply enables you to use the logical standby database for reporting activities, even while SQL statements are being applied.
Stream doc says:
Oracle Streams provides two ways to capture database changes implicitly: capture processes and synchronous captures. A capture process can capture DML changes made to tables, schemas, or an entire database, and DDL changes. A synchronous capture can capture DML changes made to tables. Rules determine which changes are captured by a capture process or synchronous capture.
And before this, I have already tried to get SQL change by analyzing redo log with oracle LogMinner and finally did it.
The Oracle stream seems to be the most appropriate way of achieving my purpose, but it implements steps are too complicated and manually. And in fact, there is an open-source for MySQL published by Alibaba which named canal, canal pretends itself as a slave so that MySQL will dump binlog and push it to canal service, and then canal reconstitutes the original SQL from binlog.
I think Oracle standby database is like MySQL slave so that the probe can be implemented in a similar way. So I want to use the data guard way, but I don't want to analyze the redo log myself since it needs root privilege to shut down the database and enable some functions, however, in production I only have a read-only user. I want to use logical standby database, but the problem is that I didn't see how to get the Reconstitutes SQL statements described above.
So, are there any pros can make some suggestions?
Anyway thanks a lot.
I am currently running a number of SQL queries on the same table in Oracle. It seems to be taking forever to run the queries. My understanding is that Oracle doesn't lock tables just to read data, however this makes me think that it is blocking. I don't care about the state of the data in the table as long as it returns a correct snapshot. Is there a way to run queries that are non-blocking?
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.