I've been asked by the publishers to review "Oracle Database 11g Release 2: Performance Tuning Tips and Techniques" by Richard Niemiec of TUSC. Conclusion: it is good but not perfect. This is an extended version of the review I put up on Amazon.
Dependency Oracle schema is the place where all the Database objects get stored. This make a room for the entire set of objects under the Category of Data Storage ( Tables, Views) and Data Access (Stored Procedure ,Functions ,Packages and Triggers) .These Objects make a reference across all these objects to form the application.This is known as dependency.
Conventional Dependency Model If an Object B is being referrd from object A (ie Object A refers another Object B) , Object A is known as Dependant Object and Object B is Known as referenced Object.
It gives me great pleasure and honour to announce my upcoming book Oracle Advanced PL/SQL Developer Professional Guide with Pact Publishers. The book 'Oracle Advanced PL/SQL Developer Professional Guide' is focussed on the preparation of OCP (1Z0-146) examination. The book doesn't restricts its scope to the examination but aims to strengthen the advanced concepts in Oracle 11g PL/SQL.
The book has been reviewed by Oracle ACEs Kamran Agayev, Ronald Rood and Mohan Dutta. It is under production and is expected to be released by May, 2012.
Basics of Partition Tables
Partitioning is a method of splitting an object (a table or index) into separate parts (called partitions) based on some criterion that is assigned to the partition. The criterion might be a date range, a number range, or any other possible value. Imagine, for example, that you have a huge table that is driving you crazy because queries on it are really slow. You get so mad at this table that you take a logical hatchet and begin to slice the table up into many smaller tables is a partition.
The old Oracle join syntax really should be consigned to history.
This single script provides the overall picture of the database in terms of Waits events, Active/Inactive killed sessions, Top Processes (physical I/O, logical I/O, memory and CPU processes), Top CPU usage by users, etc.
[code]set serveroutput on
cursor c1 is select version
cursor c2 is
, to_char(sysdate, 'HH24:MI:SS DD-MON-YY') currtime
, to_char(startup_time, 'HH24:MI:SS DD-MON-YY') starttime
cursor c4 is
select * from (SELECT count(*) cnt, substr(event,1,50)
Oracle 18.104.22.168, the second patch set for the 11gR2 database, is now certified with with E-Business Suite and is available for download in 32 and 64-bit.
You can download it from only your meta link account credential.
Patch No: 10404530
Oracle E-Business Suite Release 11i
* 22.214.171.124 + ATG PF.H RUP 6 and higher
* Linux x86 (Oracle Linux 4, 5)
* Linux x86 (RHEL 4, 5)
* Linux x86 (SLES 10)
* Linux x86-64 (Oracle Linux 4, 5)
Why do you sometimes not get partitionwise joins? Because the optimizer isn't clever enough. Reference partitioning has many benefits, one of which is that the optimizer understands it. You will always get a partitionwise join if your tables are reference partitioned.
When we launch a long operation, such as a RMAN backup or rebuild of a large index, we can come to despair of not having an estimate of the time it may take. We can even come to think that is doing nothing.
For the progress of a long operation we can query the view V$SESSION_LONGOPS, first obtaining the process ID from V$SESSION. In the case of DBA, we know exactly which user is rebuilding the index, so we can simplify it into a single query.
The following example shows the progress of the reconstruction of a partition of an index.
Several times I have had to deal with people who do not want to define constraints. I have never understood why they don't, because my experience is that the more constraints you can define, the better Oracle will perform. If anyone knows where the idea that not defining constraints is a Good Thing comes from, I would be interested to know.
Following are two very simple examples of constraints allowing the optimizer to develop better plans.
First, foreign key constraints. These give the optimizer a lot of information about the data that may mean it can cut out whole tables from a query.