Screens
The nastiest thing about Oracle is that half a script can become irreversible. The moment a DDL statement runs, it also commits whatever was pending. The product catches that trap before the request is even saved.
In Oracle, statements such as DDL, GRANT, REVOKE and TRUNCATE implicitly commit whatever was pending before them. If a script updates data and then alters a table, the update cannot be rolled back even when the alter fails.
Two separate rules detect this ordering during parsing: a statement that causes an implicit commit appearing after a data change, and DDL mixed with DML in the same script. Both surface before the request is saved.
Partial success is a state, not an accident. On Oracle an execution can stop halfway. The product treats that as its own state: for a request that failed during execution, generating and running a rollback script is allowed, because there really is a partial change to undo.
Oracle scripts are turned into a syntax tree by a grammar analyser. Rules run on that tree, so anonymous blocks, package bodies and nested structures are classified correctly.
The product can generate a rollback script. On Oracle the generated script is written to be safely repeatable and is run in full; no partial skipping is applied.
A rollback script can be made mandatory for a server, and automatic rollback generation can be enabled. These settings live on the server definition rather than a single organisation wide rule.
Critical object protection, data changes without a WHERE clause, permission changes and naming rules come from the same rule set on Oracle too. Each rule declares which database types it applies to.
Oracle is supported here as a managed target database: scripts are parsed with Oracle grammar, executed on Oracle servers and object definitions are read from them.
The database where the product keeps its own records runs on SQL Server. In other words, managing your Oracle estate requires a small record database on the SQL Server side.