This can be complex to solve. If you've got a backup, then you have an overloaded database.
You need to contact Support to get someone to help you untangle the problem.
The first step will be to change to a production-quality database. Oracle Express is not supported for production use with TM ART. The volume of data will overwhelm Oracle Express. Same applies to the Express edition of MS SQL Server. You cannot run TM ART with the free versions of the databases for anything larger than a very small proof-of-concept or demo.
But do we have any way to clear the queue...which is there in system health..
If you disconnect from the database that will throw away that backlog. That is on the System screen.
That does throw away the backlog so you do lose result data.
And you do have to have the database password to connect to the database again.
But it just might get you going again.
But if it is developing a queue then you'll most likely end up in exactly the same spot again shortly.
I understand, however data/space in the DB does not seem to be the issue. We connected to the DB manually and create a table and inserted data. The same was happening. How can we check what problem is the app facing to insert data ?
Space in the DB will be a problem very quickly once you get TM ART working. Also Express Edition has limitations in other areas that make it unsuitable for TM ART usage.
When you connect to the DB initially you must provide database credentials which can be a less-than-full-admin user. If TM ART sees that the named database doesn't exist or is empty it will then prompt for credentials again. In responding to that second prompt you must provide a full admin user ("sa" or equivalent) as it will then create tables etc.
You should open a support case and work this thru the excellent support team. They will need to collect log files and such things that are not well suited to Communities.
Thanks for the advice, I will raise a support call. Just to provide you a background, the installation was completed successfully and only after a few days of functioning that we had this problem. We suspected DB limitations which we validated were not so.
Anyway, we will work with the support team to resolve the issue. Thanks Again.
If everything is working correctly, you should not develop a queue between TM ART Central and the database for more than a few seconds. A persistent queue is a sign that the database is not capable of sustaining the load that TM ART is putting on it or that the database has failed or run out of space.
There are some things I should have mentioned about the screenshot you attached.
There are two very key numbers you need to look at, they are the last two in the upper pane.
MeasureWriteTime(limit) is the system's calculated slowest allowable time for writing a "measure" to the database given the current load. The current load is shown by the sum of MeasureCount SYN and MeasureCount REM.
MeasureWriteTime(avg) is the system's measured average actual time for writing a measure to the database.
If the latter value is larger than the former, then the database is unable to keep up. Queues will build up until everything just comes to a halt.
There is discussion of these values in the Administration Guide.
In a fairly normal system we see values in the 20-30msec range for MeasureWriteTime(avg). In incredibly well tuned systems we've seen some below 10msec. Yours is over 500msec, over 1/2 second for a database write. That's not going to be sustainable.
Hal mentioned that the System Health screen is discussed in the Admin Guide. When you take a look at that please be sure to take a look at the paragraph on the SystemHealthDivideMeasureWriteTime parameter. That will give you an even better display since it will consider the number of threads that are being used to write results.
There will be no data displayed in the TMART Central if the database is not working.
Hence, please check if the database is working fine.
There might be some changes in the database files.