Search code examples
sqlquery-optimizationsybase

Speed up this Sybase stored procedure

I have this stored procedure which I am using to populate a user table. It seems slow because it is taking around avg. 6s to return the records. Is there anything else I can do to tweak this sproc to make it faster?

CREATE PROCEDURE dbo.usmGetPendingAuthorizations
(
    @empCorpId char(8) = null,
    @empFirstName char(30) = null,
    @empLastName char(30) = null,
    @accessCompletionStatus char(20) = null,
    @ownerCorpId char(8) = null,
    @reqCorpId char(8) = null,
    @reqDate datetime = null,
    @rowCount int = 100
)
AS BEGIN       

    SET ROWCOUNT @rowCount

    SELECT
        UPPER(LTRIM(RTRIM(pa.RequestorCorpId))) AS ReqCorpId, 
        UPPER(LTRIM(RTRIM(pa.AccessCompletionStatus))) AS AccessCompletionStatus, 
        UPPER(LTRIM(RTRIM(pa.Comment))) AS ReqComment, 
        UPPER(LTRIM(RTRIM(pa.ValidLoginInd))) AS ValidLoginInd, 
        UPPER(LTRIM(RTRIM(pa.OwnerCorpId))) AS OwnerCorpId, 
        UPPER(LTRIM(RTRIM(pa.UserTypeCode))) AS UserTypeCode, 
        UPPER(LTRIM(RTRIM(pa.SelectMethod))) AS SelectMethod, 
        pa.ExpirationDate AS ExpirationDate, 
        pa.RequestorDate AS ReqDate, 
        pa.BeginDate AS BeginDate, 
        pa.EndDate AS EndDate, 
        UPPER(LTRIM(RTRIM(pa.UserGroupTypeCode))) AS UserGroupTypeCode,
        pa.SubsidiaryId AS SubsidiaryId,    
        UPPER(LTRIM(RTRIM(pa.EmployeeCorpId))) AS EmpCorpId,
        emp.empKeyId AS EmpKeyId,
        LTRIM(RTRIM(emp.firstName)) AS EmpFirstName,
        LTRIM(RTRIM(emp.lastName)) AS EmpLastName
    FROM
        dbo.PendingAuthorization AS pa JOIN capmark..EmployeeDataExtract AS emp
    ON
        UPPER(LTRIM(RTRIM(pa.EmployeeCorpId))) = UPPER(LTRIM(RTRIM(emp.corporateId)))
    WHERE
        UPPER(LTRIM(RTRIM(pa.EmployeeCorpId))) LIKE ISNULL(UPPER(LTRIM(RTRIM(@empCorpId))), '%')
        AND UPPER(LTRIM(RTRIM(emp.firstName))) LIKE ISNULL('%' + UPPER(LTRIM(RTRIM(@empFirstName))) + '%', '%')
        AND UPPER(LTRIM(RTRIM(emp.lastName))) LIKE ISNULL('%' + UPPER(LTRIM(RTRIM(@empLastName))) + '%', '%')
        AND pa.AccessCompletionStatus LIKE ISNULL(UPPER(LTRIM(RTRIM(@accessCompletionStatus))), '%')
        AND pa.OwnerCorpId LIKE ISNULL(UPPER(LTRIM(RTRIM(@ownerCorpId))), '%')
        AND pa.RequestorCorpId LIKE ISNULL(UPPER(LTRIM(RTRIM(@reqCorpId))), '%')
        AND DATEDIFF(dd, pa.RequestorDate, CONVERT(VARCHAR(10), ISNULL(@reqDate, pa.RequestorDate), 101)) = 0

    SET ROWCOUNT 0
END
Solution

  • The main problem is the liberal use of functions, especially in the join. Where functions are used in this way Sybase cannot take advantage of indexes on those fields. Take for example the join

    ON
    UPPER(LTRIM(RTRIM(pa.EmployeeCorpId))) = UPPER(LTRIM(RTRIM(emp.corporateId)))

    Are all those trims and uppers really needed?

    If you have dirty data stored - mixed case, with some leading and some trailing space, I suggest that you try to tighten up the way the data are stored and/or updated - don't allow such data to get in. Carry out a one-time scrub of the data to make all corporate Ids uppercase with no trailing or leading spaces.

    Once you've got clean data you can add an index on corporateId column in the EmployeeDataExtract table (or rebuild it if one already exists) and change the join to 

    ON
    pa.EmployeeCorpId = emp.corporateId

    If you really can't ensure clean data in the PendingAuthorization table then you'd have to leave the functions wrapping on that side of the join, but at least the index on the emp table will be available for the optimiser to consider.

    The use of LIKE with leading edge wildcards makes indexes unusable, but that may be unavoidable in your case.

    It looks like the PendingAuthorization.RequestorDate field is used to select data only for one date - the one supplied in @reqDate. You could transform that part of the WHERE clause to a range query, then an index on the date field could be used. To do that you would use just the date part of @reqDate (ignoring time of day) and then derive from that 'date+1'. These would be the values used. Whether this would help much depends on how many RequestorDate days are present in the PendingAuthorization table.