Hi,
I want to know the difference between oracle 9i and 10g.
thanks and regards
sankar
I want to know the difference between oracle 9i and 10g.
thanks and regards
sankar
-
-
Check here for 8i,9i,10g,11g features!!Originally posted by sank -
Each version of oracle docs contains New features document.Originally posted by sank
Gints Plivna
http://www.gplivna.euComment
-
Hi Sankar,
I have ne useful new features of Oracle 10g below ,but i have't mentioned many important things ..
Flashback Versions Query
SQL> desc rates
Name Null? Type
----------------- -------- ------------
CURRENCY VARCHAR2(4)
RATE NUMBER(15,10)
This table shows the exchange rate of US$ against various other currencies as shown in the CURRENCY column. In the financial services industry,
exchange rates are not merely updated when changed; rather, they are recorded in a history. This approach is required because bank transactions
can occur as applicable to a "past time," to accommodate the loss in time because of remittances. For example, for a transaction that occurs at
10:12AM but is effective as of 9:12AM, the applicable rate is that at 9:12AM, not now.
Up until now, the only option was to create a rate history table to store the rate changes, and then query that table to see if a history is available.
Another option was to record the start and end times of the applicability of the particular exchange rate in the RATES table itself. When the change
occurred, the END_TIME column in the existing row was updated to SYSDATE and a new row was inserted with the new rate with the END_TIME
as NULL.
In Oracle Database 10g, however, the Flashback Versions Query feature may obviate the need to maintain a history table or store start and end
times. Rather, using this feature, you can get the value of a row as of a specific time in the past with no additional setup. Bear in mind, however,
that it depends on the availability of the undo information in the database, so if the undo information has been aged out, this approach will fail.
For example, say that the DBA, in the course of normal business, updates the rate several times—or even deletes a row and reinserts it:
insert into rates values ('DOLL',1.1012) ;
commit;
update rates set rate = 1.1014;
commit;
update rates set rate = 1.1013;
commit;
delete rates;
commit;
insert into rates values ('DOLL',1.1016) ;
commit;
update rates set rate = 1.1011;
commit;
After this set of activities, the DBA would get the current committed value of RATE column by
SQL> select * from rates;
CURR RATE
---- -----
DOLL 1.1011
This output shows the current value of the RATE, not all the changes that have occurred since the first time the row was created. Thus using
Flashback Query, you can find out the value at a given point in time; but we are more interested in building an audit trail of the changes—somewha t
like recording changes through a camcorder, not just as a series of snapshots taken at a certain point.
The following query shows the changes made to the table:
select versions_startt ime, versions_endtim e, versions_xid,
versions_operat ion, rate
from rates versions between timestamp minvalue and maxvalue
order by VERSIONS_STARTT IME
/
VERSIONS_STARTT IME VERSIONS_ENDTIM E VERSIONS_XID V RATE
---------------------- ---------------------- ---------------- - ----------
01-DEC-03 03.57.12 PM 01-DEC-03 03.57.30 PM 0002002800000C6 1 I 1.1012
01-DEC-03 03.57.30 PM 01-DEC-03 03.57.39 PM 000A000A0000002 9 U 1.1014
01-DEC-03 03.57.39 PM 01-DEC-03 03.57.55 PM 000A000B0000002 9 U 1.1013
01-DEC-03 03.57.55 PM 000A000C0000002 9 D 1.1013
01-DEC-03 03.58.07 PM 01-DEC-03 03.58.17 PM 000A000D0000002 9 I 1.1016
01-DEC-03 03.58.17 PM 000A000E0000002 9 U 1.1011
Note that all the changes to the row are shown here, even when the row was deleted and reinserted. The VERSION_OPERATI ON column shows
what operation (Insert/Update/Delete) was performed on the row. This was done without any need of a history table or additional columns.
In the above query, the columns versions_startt ime, versions_endtim e, versions_xid, versions_operat ion are pseudo-columns, similar to other
familiar ones such as ROWNUM, LEVEL. Other pseudo-columns—such as VERSIONS_STARTS CN and VERSIONS_ENDSCN —show the
System Change Numbers at that time. The column versions_xid shows the identifier of the transaction that changed the row. More details about the
transaction can be found from the view FLASHBACK_TRANS ACTION_QUERY, where the column XID shows the transaction id. For instance,
using the VERSIONS_XID value 000A000D0000002 9 from above, the UNDO_SQL value shows the actual statement.
SELECT UNDO_SQL
FROM FLASHBACK_TRANS ACTION_QUERY
WHERE XID = '000A000D000000 29';
UNDO_SQL
----------------------------------------------------------------------------
insert into "ANANDA"."RATES "("CURRENCY","R ATE") values ('DOLL','1.1013 ');
In addition to the actual statement, this view also shows the timestamp and SCN of commit and the SCN and timestamp at the start of the query,
among other information.
Finding Out Changes During a Period
Now, let's see how we can use the information effectively. Suppose we want to find out the value of the RATE column at 3:57:54 PM. We can issue:
select rate, versions_startt ime, versions_endtim e
from rates versions
between timestamp
to_date('12/1/2003 15:57:54','mm/dd/yyyy hh24:mi:ss')
and to_date('12/1/2003 16:57:55','mm/dd/yyyy hh24:mi:ss')
/
RATE VERSIONS_STARTT IME VERSIONS_ENDTIM E
---------- ---------------------- ----------------------
1.1011
This query is similar to the flashback queries. In the above example, the start and end times are null, indicating that the rate did not change during
the time period; rather, it includes a time period. You could also use the SCN to find the value of a version in the past. The SCN numbers can be
obtained from the pseudo-columns VERSIONS_STARTS CN and VERSIONS_ENDSCN . Here is an example:
select rate, versions_startt ime, versions_endtim e
from rates versions
between scn 1000 and 1001
/
Using the keywords MINVALUE and MAXVALUE, all the changes that are available from the undo segments is displayed. You can even give a
specific date or SCN value as one of the end points of the ranges and the other as the literal MAXVALUE or MINVALUE. For instance, here is a
query that tells us the changes from 3:57:52 PM only; not the complete range:
select versions_startt ime, versions_endtim e, versions_xid,
versions_operat ion, rate
from rates versions between timestamp
to_date('12/11/2003 15:57:52', 'mm/dd/yyyy hh24:mi:ss')
and maxvalue
order by VERSIONS_STARTT IME
/
VERSIONS_STARTT IME VERSIONS_ENDTIM E VERSIONS_XID V RATE
---------------------- ---------------------- ---------------- - ----------
01-DEC-03 03.57.55 PM 000A000C0000002 9 D 1.1013
01-DEC-03 03.58.07 PM 01-DEC-03 03.58.17 PM 000A000D0000002 9 I 1.1016
01-DEC-03 03.58.17 PM 000A000E0000002 9 U 1.1011
Final Analysis
Flashback Versions Query replicates the short-term volatile value auditing of table changes out of the box. This advantage enables the DBA to get
not a specific value in the past, but all the changes in between, going as far bask as the available data in undo segments. Therefore, the maximum
available versions are dependent on the UNDO_RETENTION parameter.
How Much Longer?: Rollback Monitoring
Give users an accurate estimate of the duration of a rollback operation
Are we there yet? How much longer?
Sound familiar? These questions may come from the back seat on your way to the kids' favorite theme park, often incessantly and with increasing
frequency. Wouldn't you want to tell them exactly how much longer it will take—or better yet, know the answer yourself?
Similarly, when a long, running transaction has been rolled back, there are often several users breathing down your neck asking the same
questions. The questions are justified, because the transaction holds the locks and normal processing often suffers as the rollback progresses.
In Oracle 9i Database and below, you can issue the query
SELECT USED_UREC
FROM V$TRANSACTION;
which returns the number of undo records used by the current transaction, and if executed repeatedly, will show continuously reduced values
because the rollback process will release the undo records as it progresses. You can then calculate the rate by taking snapshots for an interval and
then extrapolate the result to estimate the finishing time.
Although there is a column called START_TIME in the view V$TRANSACTION, the column shows only the starting time of the entire transaction
(that is, before the rollback was issued). Therefore, extrapolation aside, there is no way for you to know when the rollback was actually issued.
Extended Statistics for Transaction Rollback
In Oracle Database 10g, this exercise is trivial. When a transaction rolls back, the event is recorded in the view V$SESSION_LONGO PS, which
shows long running transactions. For rollback purpose, if the process takes more than six seconds, the record appears in the view. After the
rollback is issued, you would probably conceal your monitor screen from prying eyes and issue the following query:
select time_remaining
from v$session_longo ps
where sid = <sid of the session doing the rollback>;
Now that you realize how important this view V$SESSION_LONGO PS is, let's see what else it has to offer. This view was available pre-Oracle
Database 10g, but the information on rollback transactions was not captured. To show all the columns in a readable manner, we will use the
PRINT_TABLE function described by Tom Kyte at AskTom.com. This procedure simply displays the columns in a tabular manner rather than the
usual line manner.
SQL> set serveroutput on size 999999
SQL> exec print_table('se lect * from v$session_longo ps where sid = 9')
SID : 9
SERIAL# : 68
OPNAME : Transaction Rollback
TARGET :
TARGET_DESC : xid:0x000e.01c. 00000067
SOFAR : 10234
TOTALWORK : 20554
UNITS : Blocks
START_TIME : 07-dec-2003 21:20:07
LAST_UPDATE_TIM E : 07-dec-2003 21:21:24
TIME_REMAINING : 77
ELAPSED_SECONDS : 77
CONTEXT : 0
MESSAGE : Transaction Rollback: xid:0x000e.01c. 00000067 :
10234 out of 20554 Blocks done
USERNAME : SYS
SQL_ADDRESS : 00000003B719ED0 8
SQL_HASH_VALUE : 1430203031
SQL_ID : 306w9c5amyanr
QCSID : 0
Let's examine each of these columns carefully. There may be more than one long running operation in the session—especia lly because the view
contains the history of all long running operations in previous sessions. The column OPNAME shows that this record is for "Transactio n Rollback,"
which points us in the right direction. The column TIME_REMAINING shows the estimated remaining time in seconds, described earlier and the
column ELAPSED_SECONDS shows the time consumed so far.
So how does this table offer an estimate of the remaining time? Clues can be found in the columns TOTALWORK, which shows the total amount of
"work" to do, and SOFAR, which shows how much has been done so far. The unit of work is shown in column UNITS. In this case, it's in blocks;
therefore, a total of 10,234 blocks have been rolled back so far, out of 20,554. The operation so far has taken 77 seconds. Hence the remaining
blocks will take:
77 * ( 10234 / (20554-10234) ) ??77 seconds
But you don't have to take that route to get the number; it's shown clearly for you. Finally, the column LAST_UPDATE_TIM E shows the time as of
which the view contents are current, which will serve to reinforce your interpretation of the results.
SQL Statement
Another important new piece of information is the identifier of the SQL statement that is being rolled back. Earlier, the SQL_ADDRESS and
SQL_HASH_VALUE were used to get the SQL statement that was being rolled back. The new column SQL_ID corresponds to the SQL_ID of the
view V$SQL as shown below:
SELECT SQL_TEXT
FROM V$SQL
WHERE SQL_ID = <value of SQL_ID from V$SESSION_LONGO PS>;
This query returns the statement that was rolled back, thereby providing an additional check along with the address and hash value of the SQL
statement.
Parallel Instance Recovery
If the DML operation was a parallel operation, the column QCSID shows the SID of the parallel query server sessions. In the event of a parallel
rollback, such as during instance recovery and subsequent recovery of a failed transaction, this information often comes in handy.
For example, suppose that during a large update the instance shuts down abnormally. When the instance comes up, the failed transaction is rolled
back. If the value of the initialization parameter for parallel recovery is enabled, the rollback occurs in parallel instead of serially, as it occurs in
regular transaction rollback. The next task is to estimate the completion time of the rollback process.
The view V$FAST_START_TR ANSACTIONS shows the transaction(s) occurring to roll-back the failed ones. A similar view, V
$FAST_START_SER VERS, shows the number of parallel query servers working on the rollback. These two views were available in previous
versions, but the new column XID, which indicates transaction identifier, makes the joining easier. In Oracle9i Database and below, you would have
had to join the views on three columns (USN - Undo Segment Number, SLT - the Slot Number within the Undo Segment, and SEQ - the sequence
number). The parent sets were shown in PARENTUSN, PARENTSLT, and PARENTSEQ. In Oracle Database 10g, you only need to join it on the
XID column and the parent XID is indicated by an intuitive name: PXID.
The most useful piece of information comes from the column RCVSERVERS in V$FAST_START_TR ANSACTIONS view. If parallel rollback is
going on, the number of parallel query servers is indicated in this column. You could check it to see how many parallel query processes started:
select rcvservers from v$fast_start_tr ansactions;
If the output shows just 1, then the transaction is being rolled back serially by SMON process--obviously an inefficient way to do that. You can
modify the initialization parameter RECOVERY_PARALL ELISM to value other than 0 and 1 and restart the instance for a parallel rollback. You can
then issue ALTER SYSTEM SET FAST_START_PARA LLEL_ROLLBACK = HIGH to create parallel servers as much as 4 times the number of
CPUs.
If the output of the above query shows anything other than 1, then parallel rollback is occurring. You can query the same view (V
$FAST_START_TRA NSACTIONS) to get the parent and child transactions (parent transaction id - PXID, and child - XID). The XID can also be
used to join this view with V$FAST_START_SE RVERS to get additional details.
Conclusion
In summary, when a long-running transaction is rolling back in Oracle Database 10g—be it the parallel instance recovery sessions or a user issued
rollback statement—all you have to do is to look at the view V$SESSION_LONGO PS and estimate to a resolution of a second how much longer it
will take.
Thanks & Regards,
Vinod Sadanandan
Oracle DBAComment
Comment