Anyone else running out there on Lawson LSF V10 and SQL 2014?

d-hofmann

Are you seeing database contention issues or websphere caching corruption?

Thanks,

Melissa

0911060553270289.pdf

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

unknown

We are running Lawson LSF V10 and SQL 2014. No issues. BUT - and this is important - we experienced strange issues fairly reliably when running without a restart. After 10 days straight, the system would start to "go wonky". I don't care where the problem was coming from, it could have been database, could have been websphere, whatever. Our solution is to have a once-a-week complete downtime. So each Saturday morning at 2:00 AM, all of Lawson and SQL Server comes down. At 2:15 AM, everything is brought back up. The weekly system recycle has reliably kept any problems from developing.

In your case, if you are restarting all your systems, including LSF and SQL 2014, on a weekly or more frequent basis, and still having trouble, there is definitely something wrong. I will not be able to help, sorry.

d-hofmann

We can't restart every 7 days. My users already frown that we restart every 14 days and always have since we installed Lawson 9.

But we have experienced strange issues, that seems to have stemmed from Websphere cache corruption.

(Apparently, the Websphere cache corruption has been encountered by others, but I don't know who.)

The Websphere Corruption came from too many handles with LATM, (there is a patch).

Too many handles in LATM is caused by excessive WAIT time on the database server.

The WAIT times on the database server is caused by SQL queries locking tables.

We are running SQL 2014 clustered and we have learned:

- SQL 2014 when clustered, treats table locks differently.

- docs.microsoft.com/.../set-transaction-isolation-level-transact-sql

This is the article from Microsoft Corporation about isolation levels.

- Every query in LBI has to be updated. (Some are stored procedures.)

-To prevent issues, this should be put in as the first line of the query, and it would not lock tables:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

While this was not needed in SQL 2008, it is needed in a SQL 2014 Clustered environment which we have.

Problem right now is to update every single report, and we seem to have 100's of them.

We didn't find this until after we went live on V10. And when customers launch a single report multiple times, say 6 or 10 because it didn't come back quickly enough, or they are running it for different companies simultaneously. It takes the WAIT time on the DB to over 10, which begins a slow spiral of issues from slowness, login errors.

When the query locks the tables for 2 minutes and the application can't update tables, the system spirals until it is not functioning at all. When this happens, it takes a clean reboot of everything, including the database server.

So this is my "Please learn from our mistake" with SQL 2014 Clustering. Use the "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED" for every sql query outside of the S3 code. That is every IPA query, LBI report, etc on the S3 database.

I will say that when you fail over the SQL 2014 cluster, the recovery is amazing, but the file lock is painful.

Thanks,

Melissa

0911060553270289.pdf

unknown

To add to Melissa's comment - We are running LSF 9 and LMRK 10/TM 11, both on DB2 rather than MSSQL, but we have received strong recommendations from Infor that all of our DB2 SQL queries for reporting (or anything else) should use the "for read only with ur" (uncommitted read) instruction to avoid file locking issues.

We also take down our full system weekly (Sat night) for a cold backup.

Kelly

Copyright © 2025 Infor. All rights reserved.