DB Version: 10.2.0.4
Users: TESTUSR (Table Owner)
TESTUSR_PKG (Package Onwer)
TESTUSR_APP (Application Owner)
create table test_tbl(a number);
CREATE OR REPLACE PACKAGE test_pkg AS -- spec
PROCEDURE insert_test_tbl (
PROCEDURE delete_test_tbl (
CREATE OR REPLACE PACKAGE BODY test_pkg AS -- body
PROCEDURE insert_test_tbl (
The ability to quiesce the database was introduced in release 9, but to this day I find that many people are not aware of it. It can be really useful - so let's describe it. I'll begin by positioning the quiesce capability: when is it useful. Then detail how to do it, then reverse engineer the mechanism.
Excellent book - I've just posted this review on Amazon:
Why publishing this under SQL instead of RDBMS Server?
The necessaty to create supporting indexes for foreign keys has been explained in other articles.
However writing a foolproof query to identify missing FK indexes is not so straightforward as it might look. I used to do it PLSQL, but this has proven not to scale very well and taking quite some elapsed time and system resources in databases with many thousands of tables.
Another example of what I think of as "the self-tuning database". Setting optimizer_dynamic_sampling=11 can fix many performance problems, without the DBA needing to use his brain at all.
Excellent exposition of a very effective SQL tuning metodology
The Oracle external tables feature allows us to access data in external sources as if it is a table in the database.
External tables are read-only.
No data manipulation language (DML) operations is allowed on an external table.
An external table does not describe any data that is stored in the database.
So, how do I create an external table?
To create an external table in Oracle we use the same CREATE TABLE DDL, but we specify the type of the table as external by an additional clause - ORGANIZATION EXTERNAL.
This post shows you details about a specific case where 'hash anti join' is defeated by 'nested loop anti join'.
The initial problem came to light in a very large BW system running on Oracle 126.96.36.199 when several BW loads (making use of older data in the BW system) reported missing dimension ids in the dimension tables.
In some BW systems much of the data is stored using fact tables (E-fact and F-fact tables).
The first 16 (differs) fields in these fact tables (both E and F) typically are number fields.
They are known as dimension key fields and each have a corresponding dimension table
Following a question on OTN https://community.oracle.com/message/12801175 I did another test on redo and undo, just to prove that frequent COMMIT can be bad for performance. The results surprised me. I expected that row-by-row commit would be worse then a single commit at the end of a multi-row transaction, but I hadn't expected it to be this bad. As well as being much slower, both undo and redo volumes are vastly greater.
The demand of Oracle database is very high and because of high demand, its security becomes the most concerned part of its users. Backup is the initial process you can do for your database security. However, at times, taking backup is also not sufficient and issues like backup file corruption, database damage due to virus, etc. takes place and data loss occurs.