Is Admin the FMS Admin Console's username?
Good catch Lindsay! Yes, the Admin Console's username is 'Admin' (it's a client's FMS so I hadn't thought about that, normally I would rename it to something less obvious).
So, the 'Admin' user is causing lock conflicts? I'm still none the wiser! I have had to use the command line at points to stop and start processes when the Admin console has been unresponsive, but surely this user wouldn't stay 'connected' after the event? The errors are still appearing in the logs days later...
I am seeing these same errors, except I don't have any accounts called admin! Not to get into the database, admin console or even into the Server Computer.
We have a privilege set called admin
What is the database users? and what is supposed to be in the parenthesis?
2016-11-16 14:52:01.251 -0500 Error 66 CCHFILEMAKER02 Could not pause database "MyDatabaseName" because of lock conflict(s) with 2 database user(s): Admin (); Admin ()
I am using FMS14, only started seeing this after turning on Progressives, never saw it on regular backups (but they are at night anyway).
Any live development happening on those files?
I do live development. But I only do scripting and layouts when there users in the system. And only locally, not over the wan.
If i need to go to define-> database I try to do that when users are not I. The system
when this specific error occurred, I was in scripting work space.
I not sure how useful this is, but in item 5.2 in the following thread, it states, "• 5.2. If a database is busy when a progressive backup occurs, error 66 may appear in the Event.log: Could not pause database ". If error 66 occurs, an additional IncrementalBackup_timestamp folder is created temporarily in the target folder. The progressive backup process (FMSIB) recycles this temporary folder at the next backup if there are no lock conflicts for the named database."
just had an issue today where the database locked up. I am not sure what caused it, but during the lock up, there were Error 66 notifications where the database had conflicts with admin().
There was no development going on.
Could it be when a Server Side script causes an error, the user is erroneously attributed to admin() instead of the user who initiated the PSOS?
Are you using ESS? Do you have scheduled server side scripts running or use Perform Script on Server?
Just based on the message text and the fact that users are seeing a slow down, I'd suspect that you're somehow getting a database deadlock. When this issue happens, what does the server CPU usage look like? When i've seen deadlocks happen before the CPU usage was very low even though all the users were waiting for things to happen.
Not using ESS. We are doing a lot of PSOS and Server Side scripting.
Seems like monthly we have some type of deadlock issue, since going to FMS14&15. The thing that is unnerving, is I the user name doesn't make sense. Earlier in my thread, I stated I have no users named admin. If the lock is caused by a PSOS the 'user' should be listed as the script name.