> select > ticketgran0_.ID as ID1_, ticketgran0_.NUMBER_OF_TIMES_USED as NUMBER2_1_, > ticketgran0_.CREATION_TIME as CREATION3_1_, ticketgran0_.EXPIRATION_POLICY > as EXPIRATION4_1_, > ticketgran0_.LAST_TIME_USED as LAST5_1_, > ticketgran0_.PREVIOUS_LAST_TIME_USED as PREVIOUS6_1_, > ticketgran0_.ticketGrantingTicket_ID as ticketG10_1_, > ticketgran0_.AUTHENTICATION as AUTHENTI7_1_, > ticketgran0_.EXPIRED as EXPIRED1_, ticketgran0_.SERVICES_GRANTED_ACCESS_TO > as SERVICES9_1_ > from TICKETGRANTINGTICKET ticketgran0_ > where ticketgran0_.ticketGrantingTicket_ID=:1;
That's the query to load all the child tickets for a given TGT. Recall proxy-granting tickets are modeled as children of a parent TGT. > SQL> desc ugo.TICKETGRANTINGTICKET > It contains almost 2 Million rows. That sounds like a heck of a lot. Do you have ~2M concurrent users? That would be a very large CAS install if so. > ID is the Table KEY > TICKETGRANTINGTICKET_ID is the Secondary Key "Secondary Key"? ID ought to be the table primary key and TGT_ID ought to be a foreign key back to ID. Both columns ought to be indexed such that the query above executes in O(1) time. The fact that it is "hot" may indicate you are lacking (good) indices. What platform is this again? > TICKETGRANTINGTICKET_ID is not populated -- all rows have a NULL Value. > So the SQL at the Top of page will always return Zero Rows. This would be perfectly normal if you're not issuing proxy tickets. > Why is it executing Code against a Large tables where it will always return > ZERO Rows? Presumably because you don't use proxy tickets, but the application is coded to handle the case where they would be used. Hopefully your slowness is caused simply by missing or misconfigured indices. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
