RecycleBin in Oracle10g

One of the many new features that oracle10g introduced is the recyclebin. when enabled , thisfeture works a littele bit like the familiar windows recyclebin or mac Trash. Droped tables go into the recyclebin and can be restored from the recyclebin.
   
    There are two recyclebin views: USER_RECYCLEBIN and DBA_RECYCLEBIN. For convenience, the synonyms RECYCLEBIN points to USER_RECYCLEBIN. The recyclebin is enabled by default in 10g, but you can turn it on or off the RECYCLEBIN initialization parameter, at the system or session level

When the recyclebin is enabled, any tables that you drop do not actually get deleted. Instead when you drop a table, Oracle just renames the table and all its associated objects(Indexes, triggers, LOB segments, etc) to a system-generated name that begins with BIN$

It's important to know that after you've dropped a table, it has only been renamed; the table segments are still sitting there in your tablespace, unchanged, taking up space. This space still count againt your user tablespace quotas, as well as filling up the tablespace. It will not be reclaimed untill you get the table out of recyclebin. You can remove an object from the recyclebin by restoring it, or by purging its from the recyclebin.

Ex: SQL:\> DROP TABLE TEST;
      SQL:\> SELECT * FROM RECYCLEBIN;
      SQL:\> FLASHBACK TABLE TEST TO BEFORE DROP;

     SQL:\> PURGE RECYCLEBIN

2PC(two phase distributed commit)

Q: What is 2PC(two phase distributed Commit)

Ans: Peroming a distributed transaction is similar to a local transaction.

    Update local_table set x=10;
    Update remote_table@another_database set y=20;
    commit;

    Oracle will either commit in both databases  or nither, it uses atwo-pahse distributed commit(2PC) protocol to do this. Two-Phase commit is a transaction protocol designed for the complications that rise with distributed resoure manager. with a two-phase commit protocol, the distributed  transaction manager employs acordinator to manage the individual resource managers.

The commit process proceeds as follows:

  Phase 1:
        Each participating resource manager  coordinates  local operations and forces all log records out:
        If sucessful, responds "ok"
        If unsucessful, either allow a time-out or respond "oops"

  Phase 2:
       If all participants respond "ok"
             Coordinator instructs participatnig resource  manages to "COMMIT"
             Participants complete  operation writing the log record for the commit
      Otherwise:
              Coordinator instruts participating resource manager to "ROLLBACK"
              Participants complete their  respective local undos