You are viewing limited content. For full access, please sign in.

Question

Question

Tracing the origin of a long-running query using a temporary table called search_entry_cache

asked on February 26, 2024

My client's LF 9 system periodically runs some queries on their SQL Server that take a long time to execute (up to several hours), so I'm trying to determine the origin of the queries (for example, is this a LF housekeeping function? part of the index service? etc.) All of the queries include a temporary
 sql table called either #search_entry_cache or #search_entry_cache2.

Here is one of the problem queries — does anybody recognize what might be the source of this?

Thanks,
Ken

SELECT     tocid,
           parentid,
           etype,
           vol_id,
           acl_tocid,
           (
                  SELECT Count(d.tocid)
                  FROM   ann a
                  JOIN   doc d
                  ON     a.page_id = d.page_id
                  WHERE  a.ann_type = 2
                  AND    d.tocid = toc.tocid ) AS redactions,
           CASE
                      WHEN acl_tocid IS NULL THEN - 1
                      ELSE
                                 CASE
                                            WHEN acl_tocid = tocid THEN 0
                                            ELSE
                                                       CASE
                                                                  WHEN acl_tocid = parentid THEN 1
                                                                  ELSE 2
                                                       END
                                 END
           END AS depth
FROM       toc
INNER JOIN #search_entry_cache
ON         tocid = entry_id

 

0 0

Replies

replied on February 27, 2024

I believe this table is used for search results that come from full-text search, and the query above is used to determine which of those results the current user has access to. So the table can be large depending on what search string the user submitted, but queries should not take hours. Sql Server Profiler should give you an idea of what is taking so long.

1 0
replied on February 28, 2024

Thank you, Brian--much appreciated! We continue to drill down on the source...

Ken

0 0
replied on February 28, 2024

Gentle reminder that the latest Laserfiche 9 is almost 9 years old, out of support and that there were several enhancements made to search since then.

1 0
replied on February 28, 2024

I would also add that the end of support for the latest version of 9 was December 31, 2021.

1 0
replied on February 28, 2024

Yes, I appreciate the note in the spirit in which it was given. The client has maintained their LSAP all this time and intends to upgrade--they just have a few hurdles to overcome first. Thank you!

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.