high reads

  • i have a proc who on occasion it's execution plan goes to hell and it uses 11 million reads to finish. I think it's because there is a check in the where that says user.isInactiveDate is null however i'm not certain cause it doesn't always happen.

    as a result i'm trying to create a script that will give me all the proc calls who have logical reads over, say, 10,000.

    I see how i can get the reads however not how i can get the proc name.

  • Can you post some code? Are you reading through the DMV for execution plans or something else?

  • BaldingLoopMan (8/21/2012)


    i have a proc who on occasion it's execution plan goes to hell and it uses 11 million reads to finish. I think it's because there is a check in the where that says user.isInactiveDate is null however i'm not certain cause it doesn't always happen.

    as a result i'm trying to create a script that will give me all the proc calls who have logical reads over, say, 10,000.

    I see how i can get the reads however not how i can get the proc name.

    If you show us what you have so far, we can help you a lot better.

    Jared
    CE - Microsoft

  • thats the thing. The proc only does it sometimes. i dont know why. i assume it has something to do w the indexes being rebuild however havent proven that.

    Right now its fine. it litterally goes from 11 million logical reads to 3.

    heres the code.

    ALTER PROCEDURE [dbo].[usp_tbl_staff_assisted_getbyuser]

    @col_staff_username CHAR(20),

    @usertype CHAR(1)

    AS

    SET NOCOUNT ON

    --------------------------------------------------------------------------------------------------------------------------------

    Select TOP 5

    SAss.col_id,

    SAss.col_staff_username,

    SAss.col_assist_username,

    SAss.col_assist_date,

    U.col_partial_save,

    U.col_loginname,

    U.col_userid

    From

    tbl_assisted AS SAss With (NoLock)

    Inner Join usr AS U With (NoLock) On U.username = SAss.col_assist_username AND SAss.col_staff_username = @col_staff_username

    Where

    SAss.col_staff_username = @col_staff_username

    And U.usertype = @usertype

    AND U.inactivedate IS NULL

    Order By

    SAss.col_assist_date desc

  • BaldingLoopMan (8/21/2012)


    thats the thing. The proc only does it sometimes. i dont know why. i assume it has something to do w the indexes being rebuild however havent proven that.

    Right now its fine. it litterally goes from 11 million logical reads to 3.

    heres the code.

    ALTER PROCEDURE [dbo].[usp_tbl_staff_assisted_getbyuser]

    @col_staff_username CHAR(20),

    @usertype CHAR(1)

    AS

    SET NOCOUNT ON

    --------------------------------------------------------------------------------------------------------------------------------

    Select TOP 5

    SAss.col_id,

    SAss.col_staff_username,

    SAss.col_assist_username,

    SAss.col_assist_date,

    U.col_partial_save,

    U.col_loginname,

    U.col_userid

    From

    tbl_assisted AS SAss With (NoLock)

    Inner Join usr AS U With (NoLock) On U.username = SAss.col_assist_username AND SAss.col_staff_username = @col_staff_username

    Where

    SAss.col_staff_username = @col_staff_username

    And U.usertype = @usertype

    AND U.inactivedate IS NULL

    Order By

    SAss.col_assist_date desc

    Do you want help with this stored proc, or the query you are using to find all those with reads over 10,000?

    Jared
    CE - Microsoft

  • Well other than the nolock hints I don't see anything obviously wrong with that.

    Parameter sniffing problems perhaps? Can you post the execution plan (actual plan) of an execution with the 11 million reads?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Can you post some ddl? how many rows are in these tables? It would be helpful to understand your indexes, contraints, etc.

    "I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

    -- Itzik Ben-Gan 2001

  • Hmm... My thought was that the OP wanted to know how to take information from sys.dm_exec_procedure_stats, and either cross apply it or join it to get the name of the actual stored proc. I am having trouble with this myself right now, as I am trying to really learn the dmv's.

    Jared
    CE - Microsoft

  • Cross apply to sys.dm_exec_sql_text (on the plan_handle). One of the resultant columns is Object_ID.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster (8/21/2012)


    Cross apply to sys.dm_exec_sql_text (on the plan_handle). One of the resultant columns is Object_ID.

    Ok, but if I run this:

    SELECT ps.object_id, s.objectid

    FROM sys.dm_exec_procedure_stats ps

    CROSS APPLY sys.dm_exec_sql_text(sql_handle) s I see that the columns match. These id's do not exist in any of the other dmv's "that I have looked at" (such as sys.all_objects) at least not as "object_id" where I can tie it to a name. This is where I am stuck.

    Jared
    CE - Microsoft

  • SQLKnowItAll (8/21/2012)


    GilaMonster (8/21/2012)


    Cross apply to sys.dm_exec_sql_text (on the plan_handle). One of the resultant columns is Object_ID.

    Ok, but if I run this:

    SELECT ps.object_id, s.objectid

    FROM sys.dm_exec_procedure_stats ps

    CROSS APPLY sys.dm_exec_sql_text(sql_handle) s I see that the columns match. These id's do not exist in any of the other dmv's "that I have looked at" (such as sys.all_objects) at least not as "object_id" where I can tie it to a name. This is where I am stuck.

    A HA! I see my issue. The code I am running (not for anything but learning the views right now) is this:

    SELECT DB_NAME(ps.database_id), object_name(ps.object_id), ps.max_logical_reads, ps.max_physical_reads, s.text

    FROM sys.dm_exec_procedure_stats ps

    CROSS APPLY sys.dm_exec_sql_text(sql_handle) s

    For this to return a name for the stored proc, it must be run in the context of the database that contains the stored proc. All others turn out NULL. Is there a way around this? i.e. if I wanted to see all stored procs in all databases?

    Jared
    CE - Microsoft

  • Object_id is used to join to sys.objects (or sys.procedures if you prefer). Or you can use Object_name and pass it the object_id and database_id.

    Note that sys.objects is database-specific and sys.dm_exec_procedure_stats is server-wide.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • GilaMonster (8/21/2012)


    Object_id is used to join to sys.objects (or sys.procedures if you prefer). Or you can use Object_name and pass it the object_id and database_id.

    Note that sys.objects is database-specific and sys.dm_exec_procedure_stats is server-wide.

    Thanks Gail, I think the problem was that I did not know that I could execute the OBJECT_NAME with 2 arguments; i.e. OBJECT_NAME(object_id, database_id). That gave the the desired results and should help me a lot moving forward.

    Jared
    CE - Microsoft

  • With no execution plan to see what is going on, here is one possible idea for you to try:

    ALTER PROCEDURE [dbo].[usp_tbl_staff_assisted_getbyuser]

    @col_staff_username CHAR(20),

    @usertype CHAR(1)

    AS

    SET NOCOUNT ON

    --------------------------------------------------------------------------------------------------------------------------------

    Select TOP 5

    SAss.col_id,

    SAss.col_staff_username,

    SAss.col_assist_username,

    SAss.col_assist_date,

    U.col_partial_save,

    U.col_loginname,

    U.col_userid

    From

    tbl_assisted AS SAss

    Inner Join usr AS U

    On U.username = SAss.col_assist_username -- AND SAss.col_staff_username = @col_staff_username

    Where

    SAss.col_staff_username = @col_staff_username

    And U.usertype = @usertype

    --AND U.inactivedate IS NULL

    Order By

    SAss.col_assist_date desc;

    GO

    -- Create a filtered covering index on usr for the query.

    create index idx_active

    on usr (

    usertype,

    username

    )

    include (

    col_partial_save,

    col_loginname,

    col_userid

    )

    where inactivedate is null;

    go

  • Going to try and answer everyone here.

    1) I didn't save the execution plan when it was doing 11 million reads. I wasn’t expecting it to all the sudden fix itself. I do have spotlight however so I may be able to get it.

    2)The issue at hand is why is this execution plan for this proc going to 11 million reads sometimes. Not all the time. One of our prod boxes pegs at 100 cpu during the hours or 1030 to around 1130. I traced it and found a the high read proc issue. so I wrote a version of the proc wrapping the isInactiveDate in an isnull and the plan was fine. I’ve had date issues in the past "param sniffin" where I was defaulting the date to -1 and it jacked the plan up. I digress, while I was developing my version of the proc w the isnull the original must have recompiled and stated running fine. Regardless, my version went to prod yesterday and I was thinking. when I was doing the compare between my version and the bad version, even though I was clicking generate execution plan it was still pulling the high read cached execution plan. which is another discussion all together. in my opinion if imp in ent mngr and physically click generate query exec plan it should damn well generate the plan. not pull the cached plan if it exists. therefore my change probably won’t do anything. I have to assume whatever anomaly that is occurring will negatively affect my version as well.

    3) yesterday the same thing happened w/ another proc which happens to have the same query in it. I haven’t checked however I will assume this query is probably in several procs.

    Therefore, here’s my plan.

    1) I’m going to build a process to monitor the box. If it find queries w/ extremely high reads then either drop and recreate of recompile the proc then notify us that it did so and to which proc. This should help short term and give me a better idea as to when this anomaly occurs. This is why I was asking for the read query which “SQLKnowItAll” provided which I have to say is exacltly what I needed. So thanks!

    2) identify what is causing this. I have to assume it has something to do w/ either a massive data insert of change of stats rebuild or index rebuild. One I find this I’ll be clear and the people I can sleep at night. Have any of you run into this sort of thing before?

    I’m going to try and get the plan and if I do I’ll pass all the indexes and sample data and schemas too.

    side note:

    The DB is over 2 terabytes and the prod box has 80 cores. it's an absolute monster!!! sql server 2008 rs ent. Typically runs at under 10 cpu and what i'm most impressed w is it on average does 1.2 mill logical reads per ms and 1.1 thousand physical reads per ms. lol. 500 gigs of cache. so basically everything is running from cache. that's insane. When the issue occured and it pegged at 100% cpu there was 8 million reads per ms.

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic. Login to reply