I have a non-redundant SX2000 with a major alarm. When I do a dbms check full, I have 3 view errors. The errors are Read tuple errors on View 39 ss4_line_data, view 123 rem_busy_lamp_in, and view 125 ss4_blg. Prior to the alarm and view errors, I deleted an analog extension (x213) and re-created it as a digital extension. I think the view errors are related to a multiline set key assignment on another digital extension (x102) that had x213 as a line appearance. I did not delete the line appearance before deleting the extension. When I try to view the multiline set key assignment for x102, I get an error reading the form. Is there any way to fix this without doing a data restore? Maybe by deleting x102 and re-creating it? Re-create x213 as an analog extension? Or would this just create more problems? Thanks in advance for your advice.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
SX2000 view errors 3
- Thread starter Jrme
- Start date
-
1
- #2
-
1
- #3
Sometimes I have been able to correct these errors by restoring the exact programming that was removed. You could try that and run another dbms check however it is more then likely that it will be like SXWizard says and you will have to do a database save/restore to correct.
I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
-
1
- #4
MitelInMyBlood
Technical User
I would tend to agree w/SxWizard.
Without spending a lot of time screwing around with things, the only way to reliably fix a corrupted database is to take a fresh backup (DATA SAVE to external media) and then (on a non-redundant system such as yours) perform a DBMS FLAG OFF, then restart the system into a blank database, (full system outage at this point) then format the hard drive (always recommended) and perform a DATA RESTORE (from your freshly created backup) then when it completes, reboot one final time.
Obviously you're going to have some significant down time, perhaps an hour or more on a non-redundant system. Do this after hours.
If you've never performed these procedures before then I'd urge you to retain the professional services of a Mitel-Certified technician who has. A Data Save/Data Restore process is not difficult, but there is an event sequence to follow. Hopefully your system is not running FLEX DIMS.
LoopyLou's suggestion would (at best) be only a shot in the dark, but maybe worth a try if you know what you're doing. Honestly I'm a little surprised system programming even allowed you to deprogram something that was a key app on a multiline set. If after deleting the newly created multiline set and recreating the single line set you are still not able to pull up the Multiline Set Key Assignment form for ext 102, then the party's over.
However, if you are successful, then I'd next want to do a DBMS SAVE, followed by a new DBMS Check. If you still have errors, then DATA SAVE/RESTORE is the only available fix.
Original MUG/NAMU Charter Member
Without spending a lot of time screwing around with things, the only way to reliably fix a corrupted database is to take a fresh backup (DATA SAVE to external media) and then (on a non-redundant system such as yours) perform a DBMS FLAG OFF, then restart the system into a blank database, (full system outage at this point) then format the hard drive (always recommended) and perform a DATA RESTORE (from your freshly created backup) then when it completes, reboot one final time.
Obviously you're going to have some significant down time, perhaps an hour or more on a non-redundant system. Do this after hours.
If you've never performed these procedures before then I'd urge you to retain the professional services of a Mitel-Certified technician who has. A Data Save/Data Restore process is not difficult, but there is an event sequence to follow. Hopefully your system is not running FLEX DIMS.
LoopyLou's suggestion would (at best) be only a shot in the dark, but maybe worth a try if you know what you're doing. Honestly I'm a little surprised system programming even allowed you to deprogram something that was a key app on a multiline set. If after deleting the newly created multiline set and recreating the single line set you are still not able to pull up the Multiline Set Key Assignment form for ext 102, then the party's over.
However, if you are successful, then I'd next want to do a DBMS SAVE, followed by a new DBMS Check. If you still have errors, then DATA SAVE/RESTORE is the only available fix.
Original MUG/NAMU Charter Member
- Thread starter
- #5
Thanks for the great responses. I tried LoopyLou's suggestion and got it down to 1 view error 123 rem_busy_lamp_in. I did a data save, and I'm restoring tonight per everyone's advice. I'm also surprised it allowed me to delete the extension without a warning, and I hate to admit, this is the second time this has happened (2-3 yrs ago). Since this is the only system I maintain and rarely make changes, I forgot to check. I've learned my lesson now! I'll let you know how things go.
- Thread starter
- #6
- Thread starter
- #7
Okay, last night I did the data save, dbms flag off, panel enable+reset, data restore, dbms save, & dbms check. Reset default usernames, passwords, and thresholds. Then, I deleted the analog line properly and programmed the digital line. After an hour and a half, the system was back up with no view/table errors, no faults on the db, & no alarms! Thanks again for your guidance!
- Status
Similar threads
- Locked
- Question