IP3300 database error after DBMS check

[KAS55]

Hi. One of the IP3300 controllers in the estate has reported a database error as follows after completing the DBMS check:

DBMS (DBTAUDIT): Verify_ss4_messageQ Referencing a nonexisting record, (table 16, record 374 from record 48)

Does anyone know what this is referencing please?

Also, I am planning to carry out a database backup/restore to resolve it. Is there another method available to clear it without doing the restore?

Thanks

 

[kwbMitel]

Did this error occur only once?

Have you tried initiating a DBMS Check Full?

Does the site have Hotel Features Enabled - PMS specifically?

Database backup / restore is the Last effort, not the first.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[KAS55]

Hi kwbMitel.

The first occurance was about a week ago, and every morning since then the same error is reported.

I havent tried DBMS Check Full yet - I can do that frist thing tomorrow and let you know the outcome via this thread.

There are no Hotel features enabled

Thanks for the comment on the restore task - I had expected that to be the case but thought best to ask.

Does that error message refer to a particular configuration entry?

Thanks for your help.

 

[kwbMitel]

I am not conversant in the individual tables and their functions.

Here is my best guess:
Verify_ss4_messageQ Referencing a nonexisting record

A key on a Multibutton phone exists that is referencing:
- A Mailbox that no longer exists (MWI Key)
- an Acd path that no longer exists (Specific Threshold Alert)
- Something else that does not come to mind.


*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[KAS55]

Thanks kwbMitel.

I will post the DBMS Check Full result tomorrow morning.

I will check for what you suggest - on that controller we do have 2 ACD paths and the associated agents, some of which have just been changed/deleted, so that may be the right area!

 

[SXWizard]

About the only way to fix this issue is to do a db backup, issue the maintenance command <dbms flag off>, re-boot the system (this deletes the db) and then restore the db. This will "clean up' any database (dbms) errors.

 

[kwbMitel]

Yes, SX-wizard, I agree. But it shouldn't be the first step.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[KAS55]

Hi kwbMitel,and SXWizard.

The DBMS Check Full was run this morning, it reported the same failure.

Is there anything else to try before the backup/restore?

Thanks

 

[james1982]

I always backup and restore with database errors, from my experience even if you do manage to clear the original anomoly it always returns.

 

[LoopyLou]

As suggested the best way to fix is a backup and restore. As kwbMitel suggests its something missing in the set programming. Once I was able to fix a dbms check error by restoring the programming. I was only able to do this because I knew exactly what I removed ( and it was only one thing ) the previous day. Again be save and do the backup and restore.

 

[kwbMitel]

James1982: Re:

I always backup and restore with database errors, from my experience even if you do manage to clear the original anomoly it always returns.

This behaviour would be quite unusual. I wonder if the site where you experienced this issue was using PMS integrations.

If this were the case, you should be advised that PMS communications have a higher priority on the DB than a DBMS check. If a DBMS check is being run at the same time that a change is made to the DB via a PMS intruction then a DBMS failure is likely. Running the DBMS check again will usually clear the error as the DB's are back in synch. With this scenario, Backup / Restore would be inconveniencing the customer needlessly.

Something to think about, no?

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[TrunkMan]

if you type in dbtab 16, it would come up with :

sws_brdcst_grp

some bcast gruop is causing the problem, you can also type in dbtab 16 374. Which is the specific record that is causing the fault. But im still trying to find a correlation between the hex values returned and how to read it.