DBAsupport.com Forums - Powered by vBulletin
Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: drawbacks of using v_$ tables

  1. #11
    Join Date
    Dec 2002
    Location
    Bangalore ( India )
    Posts
    2,434
    Originally posted by slimdave
    until the time when the v_$ view changes in a way that would break any existing queries against V$, at which point V$ becomes a view and is constructed to prevent queries against it from being broken by an upgrade.
    funky...

    "I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."

    "Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"

  2. #12
    Join Date
    Nov 2002
    Location
    New Delhi, INDIA
    Posts
    1,796
    Originally posted by slimdave
    Maybe they are by default created as synonyms
    They are created by default when catalog.sql is executed. So even if a patch is applied which may change the base tables, both views and the synonyms are dropped and recreated.

    Any way v$ is always better, let the v_$ be hidden from developers
    Amar
    "There is a difference between knowing the path and walking the path."

    Amar's Blog  Get Firefox!

  3. #13
    Join Date
    Aug 2002
    Location
    Colorado Springs
    Posts
    5,253
    Originally posted by abhaysk
    i) Oracle creates a new V_$something view.
    ii) It's new, so Oracle puts a V$SOMETHING synonym against it.
    iii) People and 3rd party application developers (eg. TOAD) access the V$SYNONYM table for creating support scripts.
    iv) in a later release the V_$SOMETHING view changes, dropping a column and adding others that provide the same info in a different format.
    v) to retain backwards compatibility, the V$SOMETHING synonym is dropped in the upgrade process and a view V$SOMETHING is created which makes it look like therewas really no change, or the only changes were new columns.

    It's just a theory.
    David Aldridge,
    "The Oracle Sponge"

    Senior Manager, Business Intelligence Development
    XM Satellite Radio
    Washington, DC

    Oracle ACE

  4. #14
    Join Date
    Dec 2002
    Posts
    18
    Thanks for all your replies...

    The reason I asked the question is that I can't seem to use v$backup in my PL/SQL package... if I login as SYS and grant 'select' on v$backup to a user, it won't let me (got this error: ORA-02030: can only select from fixed tables/views)... on the other hand, granting a 'select' on v_$backup allows me to do it... so I guess I may not have an option but to use v_$backup on my package... just want to know why would oracle advise us not to use v_$ views...

    Thanks again for your insights....

  5. #15
    Join Date
    Dec 2002
    Location
    Bangalore ( India )
    Posts
    2,434
    Originally posted by toshi
    on the other hand, granting a 'select' on v_$backup allows me to do it... so I guess I may not have an option but to use v_$backup on my package... just want to know why would oracle advise us not to use v_$ views...
    When you grant for the underlying table (v_$backup), you could use SYNONYM V$BACKUP in ur proc, provided grant is exclusive to user & not by any role.
    funky...

    "I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."

    "Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"

  6. #16
    Join Date
    Feb 2003
    Location
    INDIA
    Posts
    96
    v_$ are views derived from x$ tables, sometime if u know x$ tables, u will get some good insight of Oracle, specially in performance and tuning, Oracle not recommending and distributing details of x$ tables.

    while v$ are synonyms of v_$ views.

    cheers
    Dilip Patel
    OCP 8i

    Catch me online at Yahoo: ddpatel256

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width