sx2000 dbms flag question

The docs say that when the system is restarted or reloaded (or rebooted?) and the "dbms flag (is) off", the system will come back up with a blank database. I assume that I need to set the dbms flag to "on" so that I don't wipe out the database? I'd like to start running daily dbms checks and weekly prog reboots, but I dont want to screw up and lose the db.

Here's the current dbms stat

DBMS info: Lab Default DB is off DBMS info: DBMS_INITIALIZED is on DBMS info: Journal is on DBMS info: Debug is off DBMS info: Cab: 5 Dim: 12 Traffic: 5 DBMS info: Check is off

I did do a dbms flag off a few months back when I loaded some new options. But I dont know if I had to set it back on, or if it's on automatically after the system comes back up with a blank databse.

Thanks in advance Dave

Reply to
Henry Cabot Henhouse III
Loading thread data ...

"DBMS_INITIALIZED" is the flag Anytime you set the DBMS Flag "OFF" before rebooting, the system will come up with a blank (default) database. Never use the DBMS Flag Off command unless you're loading new options or performing some operation that specifically requires it.

The DBMS Flag ON command is an invalid command.

Valid DBMS commands are: DBMS CHECK DBMS CLIENT DBMS FLAG OFF DBMS STATUS DBMS SAVE

There is no risk of "losing" your database by performing daily DBMS checks or weekly programmed reboots.

As always, it is very wise to keep a current "DATA SAVE" on some type of offline media, either on RSD or TAPE or saved on some external computer disk media as in the case of OPS_Man

Reply to
wdg

DBMS DOWNLOAD without qualifiers should (IIRC) copy the database from the harddisc to RAM and in doing so, set DBMS_INITIALIZED to ON. (Preparing to be shot down in flames now...)... but I think the database is still intact on the hard disc following a DBMS FLAG OFF and then a reboot, so DBMS DOWNLOAD should re-instate the database.

Reply to
Proteus

When you first install software and options the flag will be off. Do a data restore and the flag is still off. Do a data save and the flag is on and will remain that way unless you turn it off.

DBMS checks will not turn off the flag. I always run DBMS checks. Just don't schedule them during an activity switch or they will never finish.

Reply to
DPGumby

Probably best not to schedule them anytime (or close to the time) something else is happening or scheduled to happen. I know this makes absolutely no sense, but we used to perform voice mail message wtg refresh starting at 5 AM, the same time the scheduled DBMS check was set to kick off. When we did this we had complaints almost every day about a small nbr of MSG lamps being OFF when they should have been ON. By changing the scheduled DBMS check to start at 04:00 instead of 05:00 all of a sudden our MSG WTG problems vanished completely.

Reply to
wdg

Err.. don't you mean "DBMS save" ?

Reply to
wdg

Nope I mean a data save. When you first install software, add the options and restore a database, the flag is off. I then do the data save and it turns on. I think it even says at that point to do a data save. Data save not the same as DBMS Save. I am trying to remember the difference.

Reply to
DPGumby

I'd be willing to put some money on it being a "DBMS save" that sets the flag.

In a literal sense a "DBMS SAVE" copies the database forms data (but not the forms) from dynamic ram of the plane you are addressing to the hard drive of the same plane. By comparison, a "DATA SAVE" captures the forms structure along with their contents, insuring that bits and bytes are properly formed. For this reason it is possible to recover from a corrupted file system (database corruption) with a DATA SAVE while it is not possible to do so with a DBMS save. Compare to DBMS SAVE implying "raw" data and "DATA SAVE" implying formatted data. The DBMS file is what gets corrupted while the DATA file can never be. (In a data save it is possible to have some of the forms data missing but it cannot ever be mal-formed, ie, corrupted). When you perform a "data restore" from a previous "data save" you will occasionally see a warning message stating "bad data, correct via CDE" and upon closer reading it will tell you which form and what entry failed to restore. Not so with a DBMS download because it's raw data.

Additionally, a "DBMS SAVE" is *not* a backup, while a "DATA SAVE"

**IS** a backup. True, you can perform either process to external or removable media, but you can only restore a corrupted file system from a DATA SAVE.
Reply to
wdg

Its a DBMS save that set the flag on, A data save might as well but normaly you just issue a dbms save to set the flag

FWIR the datasave saves all tables including empty one a dbms save just saves the data fom tables.

Reply to
Ian

You know now that I think of it you are right it is DBMS Save. Sorry its been a while.

Reply to
DPGumby

Hi

well thats sort of true. But on quie a few occasions when no datasave has been avalible after a system crash i have used a dbms save to rebuild the system

Its simple Load the os from rsd apply all the options restart do a datasave do a dbms download from the dbms save you have do a datasave do a data restore to find any database errrors

I cant say it will always work but it has for me.

Ian

Reply to
Ian

In such a situation I might be looking for a new service company. Of course w/OpsMan DataSaves can be automated, but without OM whoever is doing the MACS darn well better be performing routine backups or else be looking for another job. Prior to clustering & OpsMan we had shown one of the night crew in the computer room how to perform DataSaves and it became their responsibility every Friday evening. The following Monday morning there'd always be an envelope in our mail chute with an RSD disk in it. Of course there was also a copy of the most recent datasave on the hard drive, but that's not a lot of use to you when the head carves a path into the platter. File-Redundant systems soften that blow considerably.

Why a datasave at this point? Normally this is the point where you'd do a data restore (if you had a data save)

I watched a Product Support guy go through a similar exercise on an old SX2000 "VS" one time when I had occasion to visit the Kanata operations (for training). It wasn't a very elegant process tho he did manage to get the system up in spite of the fact that everything done since the DBMS save was created was lost. I recall him saying one of the keys in being able to rebuild a system from a DBMS save was in finding out what version of software the DBMS save was made under. Unlike a DATA save there isn't a conversion utility for a DBMS Download.

Reply to
wdg

Or never been shown how to do them ...

Yes.. been there and done that a few times. Their new system is a LOT better, practically flawless! Back in the days of the Black Boxes we used to make bets w/each other how many times it would them to generate a "correct" MOSS sheet when we did a software upgraded or added an option. The average was 3.

One's ability to remain focused under fire and persevere until successful in spite of insurmountable odds is always a salient feature. I work for a COAM customer and in 19 years and across multiple Mitel platforms have never once had to resort to bringing in a hired gun from the local service agency. We've always done it all, from power & grounding to CDE and MACS. I believe ours might actually be one of the largest 48v DC-powered SX2000s in operation today. There are 45 cans in all. 3 redundant control nodes, 8 full DSU nodes and 34 per nodes (peripheral expansion, obviously). The DC power is also dual redundant w/backup generators. Somewhere out there on the switchroom floor there's a couple 3300s folded into the mix for good measure. Yes, clustered.

Reply to
wdg

Not sure why, as you say its the customers responsibilty. In all cases the customers had not done any datasaves, or the media was corrupt or they had lost them.

ah the perfect world.

You get a datasave of a blank database but with the options enabled.

Quite true.

I think the "dirtyest" restore I had to do was a few months ago at a hotel, Who had a currupt harddrive on a microlite but had lost the MOS sheet and password, and the system software. When contacting Mitel(UK) the sysid of the system refered to another system in Ireland!!!! (Good old Mitel). To get it back and restored to new harddrive I did an old trick from SG days, That is drop the drive from 1 inch onto its side, put it back, boot the system, which now booted did a vol copy to rsd then with another software disk i had, did a vol restore. and its still going today.. But I was sweating a bit. As a freelance you do have to fly by the seats of your pants a bit, but when it goes well it does mean the dealer keeps using you.

Ian

Reply to
Ian

Hi DC lights never took off over here. But as size goes, I had one site that was 5 full nodes running the central site plus 4 systems remote to main site, this is something like 9 or so 3300 plus a couple of SX2000s for Operators. also one Uni had 19 nodes all clustered. and Mitels largest OPS man was at the time I was there 56 nodes being a mixture of clusters and remote sites.

Ian

Reply to
Ian

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.