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

Question

Question

Automatic Re-index of the Laserfiche database after upgrading from 8.3 to 9.2?

asked on March 16, 2015

We have a Client who currently on their production server can run template field searches but Laserfiche Client logs them out at the 20 minute mark (Repository set to logout user automatically after 20 minutes) before any results can be displayed. Meaning the search takes an excess of 20 minutes without returning results at the least.

Used the same database and upgraded Client to 9.2 in a test environment (installed 8.3 Server, registered repository & upgraded to 9.2.0). After the 9.2 database upgrade completed, I tried the same field search in 9.2 and it also ran until the user was logout without displaying results.

Waited about 45 - 90 minutes with the only changes to the system being setting the auto logout to never. When I run a search now for the same template fields as above, the search results are returned under 6 seconds. This same search would not return results under 20 minutes right after the upgrade to 9.2.

Is there a re-indexing of the Laserfiche Database that runs in the background after the upgrade to 9.2?

The major differences between the production and test are as follows:

Production: LF Server: Windows 2008 R2 SP1 with 12 GB of RAM and SQL server is Windows Server 2008 R2 SP1

Test: LF Server: Windows 2012 R2 Standard with 32 GB of RAM and SQL Server is 2012 R2 with 32 GB of RAM.

 

Any thoughts?

 

I know the resource improvement is significant but the same results was not attained right after the upgrade process.

 

0 0

Replies

replied on March 16, 2015

Hi Karim,

 

If the search results when doing a template search is taking a long time I would be tempted to think your SQL server is the bottleneck here and would focus on what has changed there.

 

There isn't a DB change when migrating from 8.3 to 9.2 as far as I know. Never heard of an issue linked with the auto log out setting either. Strange.......

0 0
replied on March 16, 2015 Show version history

As Chris said, likely an SQL issue. How large is the database?  Do you know if this SQL server is on a maintenance plan where it reorganizes/rebuilds indexes? Check fragmentation levels on the indexes in the propval table, specifically the propval_str_val_ix and propval_short_str_val_ix it. I imagine rebuilding them will fix the issue.

0 0
replied on March 17, 2015

The database size is about 125 GB and the SQL server is not on a maintenance plan.

0 0
replied on March 17, 2015

Hi Karim,

 

The more I think about this the more I lean towards it being something very wrong with SQL. Do you have a DBA you can call on to look at SQL for you?

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

Sign in to reply to this post.