DBAsupport.com Forums - Powered by vBulletin
Results 1 to 7 of 7

Thread: No. of full table Scans

  1. #1
    Join Date
    May 2002
    Posts
    193
    Dear All,

    I would like to know as to how many full table scans were happening on my database at any point of time. How do I find out.

    Regards,

    K.Diwakar

  2. #2
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    Query from v$session_longops.

  3. #3
    Join Date
    Jul 2000
    Posts
    521
    v$session_longops will not necessarily give you FTS count.

    The best way will be to automate a process that will capture SQL statements that are running at a goven time and see their plans for FTS.

    But basically, what the use of 'how many' FTS ?
    svk

  4. #4
    Join Date
    Feb 2000
    Location
    Singapore
    Posts
    1,758
    Code:
    select name, value from v$sysstat
    where name like '%table scans%';
    The value for "table scans (short tables)" and "table scans (long tables)" relate to FTS.

    HTH
    Sanjay

  5. #5
    Join Date
    May 2002
    Posts
    193
    Originally posted by tamilselvan
    Query from v$session_longops.

    Thank you verymuch sir...

    K.Diwakar

  6. #6
    Join Date
    May 2002
    Posts
    193
    Originally posted by SANJAY_G
    Code:
    select name, value from v$sysstat
    where name like '%table scans%';
    The value for "table scans (short tables)" and "table scans (long tables)" relate to FTS.

    HTH
    Sanjay
    Thank you sanjay..

    K.Diwakar

  7. #7
    Join Date
    May 2002
    Posts
    193
    Originally posted by svk
    v$session_longops will not necessarily give you FTS count.

    The best way will be to automate a process that will capture SQL statements that are running at a goven time and see their plans for FTS.

    But basically, what the use of 'how many' FTS ?
    Sir,

    I do agree with you but when you are given a database, at a given point of time, this could give you an idea of as to if the problem in the database is due to the full-tablescans that are consumiming the resources. This could be substantiated by the execution plans of the sql-sttements hitting the sqlarea.

    Excuse me if Iam wrong..

    K.Diwakar

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