[Building Sakai] SQL causing db server load

Benito J. Gonzalez bgonzalez2 at ucmerced.edu
Tue Dec 14 17:45:09 PST 2010


Sorry, forgot to add we are running rSmart CLE version 2.6.1 on Oracle 
Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit on Solaris 10.

Benito J. Gonzalez
Manager, Enterprise Web Application Development
Information Technology Department
University of California, Merced
Desk: 209.228.2974
Cell: 209.201.5052
Email: bgonzalez2 at ucmerced.edu


On 12/14/10 16:56, Benito J. Gonzalez wrote:
> Hi all,
>
> Our DBA found a select statement that is causing havoc on our database
> server:
>
>      SELECT assignment0_.ID                AS ID537_,
>         assignment0_.VERSION                AS VERSION537_,
>         assignment0_.GRADABLE_OBJECT_ID     AS GRADABLE4_537_,
>         assignment0_.STUDENT_ID             AS STUDENT5_537_,
>         assignment0_.GRADER_ID              AS GRADER6_537_,
>         assignment0_.DATE_RECORDED          AS DATE7_537_,
>         assignment0_.POINTS_EARNED          AS POINTS8_537_,
>         assignment0_.IS_EXCLUDED_FROM_GRADE AS IS9_537_
>      FROM GB_GRADE_RECORD_T assignment0_,
>         GB_GRADABLE_OBJECT_T gradableob1_
>      WHERE assignment0_.GRADABLE_OBJECT_ID=gradableob1_.ID
>      AND gradableob1_.GRADEBOOK_ID      =:1
>      AND gradableob1_.REMOVED           =0
>      AND assignment0_.OBJECT_TYPE_ID  =1
>      ORDER BY assignment0_.POINTS_EARNED
>      /
>
>
> I managed to improve the situation with the following two indices:
>
>       create index GB_GRADEABLE_OBJ_GB_RM_ID_IDX on
> GB_GRADABLE_OBJECT_T(GRADEBOOK_ID,REMOVED,ID);
>       create index GB_GRADE_RECORD_GO_T_IDX on
> GB_GRADE_RECORD_T(GRADABLE_OBJECT_ID,OBJECT_TYPE_ID);
>
> Still seems a significant amount of sorting going on for this query.
> Anyone else found a solution for this SQL's performance?
>
> Thanks!
>


More information about the sakai-dev mailing list