You are hereSupport / Ask The Community / FZEDB1 service which failed to start because of the following error:
FZEDB1 service which failed to start because of the following error:
The Heroix Longitude Consolidator Service service depends on the MAXDB: FZEDB1 service which failed to start because of the following error:
After starting, the service hung in a start-pending state
I followed KB109 to migrate settings to a new Longitude server.
the first time I tried the restore, I left a character out of the "database.bak" file name and the restore failed.
I tried again and used the correct name "database.bak"
The new install was to the same location as the previous installation.
The restore was successful.
I logged in and observed the objects I'd created in the previous location, and collections were working.
Then, because the server name had changed, I re-licensed with the file provided by Longitude using the new FQDN.
After a Windows update install, I restarted the server.
At that point, I could not see any of my collections, and the windows system event log reported the error quoted at the top of this description.
I'm pasting the contents of a diagnostic file knldiag.err:
--------------------------------------------------------------------------------
Date Time TID(hex) Typ MsgID Label Message-Text
--------------------------------------------------------------------------------
2010-03-04 11:06:15 --- Starting GMT 2010-03-04 17:06:15 7.6.03 Build 015-123-173-107
2010-03-04 16:59:10 ___ Stopping GMT 2010-03-04 22:59:10 7.6.03 Build 015-123-173-107
2010-03-04 16:59:12 --- Starting GMT 2010-03-04 22:59:12 7.6.03 Build 015-123-173-107
2010-03-04 17:01:47 0xD14 ERR 18500 IO Wrong file or device name 'D:\Longitude\datase.bak'
2010-03-04 17:01:47 0xC94 ERR 52012 RESTORE error occured, basis_err 3700
2010-03-04 17:01:47 0xC94 ERR 6 Recovery Data recovery failed
2010-03-04 17:01:47 0xC94 ERR 1 Backup + Backupmedium #1 (D:\Longitude\datase.bak) invalid file or device name [2]
2010-03-04 17:01:47 0xC94 ERR 6 KernelCo + Backup error occured, Error code 3700 "hostfile_error"
2010-03-04 17:01:47 0xC94 ERR 17 SrvTasks + Servertask Info: because Error in backup task occured
2010-03-04 17:01:47 0xC94 ERR 10 SrvTasks + Job 1 (Backup / Restore Medium Task) [executing] WaitingT53 Result=3700
2010-03-04 17:01:47 0xC94 ERR 6 KernelCo + Error in backup task occured, Error code 3700 "hostfile_error"
2010-03-04 17:02:45 0x3E4 ERR 18500 IO Wrong file or device name 'D:\Longitude\datase.bak'
2010-03-04 17:02:45 0xC94 ERR 52012 RESTORE error occured, basis_err 3700
2010-03-04 17:02:45 0xC94 ERR 6 Recovery Data recovery failed
2010-03-04 17:02:45 0xC94 ERR 1 Backup + Backupmedium #1 (D:\Longitude\datase.bak) invalid file or device name [2]
2010-03-04 17:02:45 0xC94 ERR 6 KernelCo + Backup error occured, Error code 3700 "hostfile_error"
2010-03-04 17:02:45 0xC94 ERR 17 SrvTasks + Servertask Info: because Error in backup task occured
2010-03-04 17:02:45 0xC94 ERR 10 SrvTasks + Job 1 (Backup / Restore Medium Task) [executing] WaitingT53 Result=3700
2010-03-04 17:02:45 0xC94 ERR 6 KernelCo + Error in backup task occured, Error code 3700 "hostfile_error"
2010-03-04 17:03:27 0xC94 ERR 52012 RESTORE error occured, basis_err 3310
2010-03-04 17:03:27 0xC94 ERR 6 Recovery Data recovery failed
2010-03-04 17:03:27 0xC94 ERR 17 SrvTasks + Servertask Info: because Error in backup task occured
2010-03-04 17:03:27 0xC94 ERR 10 SrvTasks + Job 1 (Backup / Restore Medium Task) [executing] WaitingT53 Result=3310
2010-03-04 17:03:27 0xC94 ERR 6 KernelCo + Error in backup task occured, Error code 3310 "devsize_too_small"
2010-03-05 14:01:23 --- Starting GMT 2010-03-05 20:01:23 7.6.03 Build 015-123-173-107
2010-03-05 14:43:18 0x600 ERR 18431 MESSAGES Could not write to event log, rc = 5
2010-03-05 14:43:20 ___ Stopping GMT 2010-03-05 20:43:20 7.6.03 Build 015-123-173-107
2010-03-05 14:45:28 --- Starting GMT 2010-03-05 20:45:28 7.6.03 Build 015-123-173-107
2010-03-05 15:39:46 0x5F8 ERR 18431 MESSAGES Could not write to event log, rc = 5
2010-03-05 15:39:47 ___ Stopping GMT 2010-03-05 21:39:47 7.6.03 Build 015-123-173-107
2010-03-08 13:12:13 --- Starting GMT 2010-03-08 19:12:13 7.6.03 Build 015-123-173-107
2010-03-09 13:12:36 ___ Stopping GMT 2010-03-09 19:12:36 7.6.03 Build 015-123-173-107
2010-03-09 13:12:43 --- Starting GMT 2010-03-09 19:12:43 7.6.03 Build 015-123-173-107
2010-03-09 13:39:19 0x10EC ERR 18431 MESSAGES Could not write to event log, rc = 5
2010-03-09 13:39:20 ___ Stopping GMT 2010-03-09 19:39:20 7.6.03 Build 015-123-173-107
2010-03-09 13:41:25 --- Starting GMT 2010-03-09 19:41:25 7.6.03 Build 015-123-173-107
Could you try restoring the database again? The logs don't look like it's been restored correctly - the restore commands are in item number 3 in the section on restoring from backup.
I can see the error with the filename at 2010-03-04 17:02:45. I also see another failure at 2010-03-04 17:03:27:
ERR 6 KernelCo + Error in backup task occured, Error code 3310 "devsize_too_small"
If you see this error when you try to restore again, it may be that your backed-up DB is large enough that it can't fit into the Volume allocated by a default installation. The restore cannot extend the DB size. If that is the case, you can fix it by re-installing Longitude, and specifying that you will be monitoring 350 servers, instead of the default value of 100. This will cause the installation to create a 10 GB volume that can hold the entire restored DB, whereas the default 3 GB volume is probably too small. You can also choose a value somewhere between 100 and 350 to size the volume between 3 and 10 GB.
Be aware that the next time MaxDB wants to extend the DB it'll use another 10 GB extension (or whatever size was initially created during install), so ensure that you have enough space for future data collections. At any given time, it's best to have enough space to hold the DB and a temporary image of it used by MaxDB for creating a backup. Since Longitude uses 365 days as the retention period for most data sets, the DB size will stabilize after a year, except for new systems and devices added. So using our 10 GB example, and assuming you expect the DB size to stabilize around 10-14 GB (reasonable assumption for most users), you want to plan for a Logical Disk of about 45 GB or more: 20 GB for the DB plus 20 GB for the temporary backup image, and 5 GB or more for other sundry files like DB logs, etc.
dbmcli on fzedb1>db_connect
ERR
-24798,ERR_DATAFULL: Data area is full
Hi, Chris
I somehow skipped right over your post. Can I use the WEB DBM to increase the size without having to reinstall?
I'm not sure if you can get to the WebDBM, if the DB isn't running properly; but if you can, that may allow you to create a large enough space. I'm not sure if MaxDB requires that the restore go into a single volume, which would push us on to plan C, which is reinstalling Longitude with a larger initial Volume.
I got in to the webdbm, tried to add a volume, and got:
-24988 SQL error
-104 DBM command impossible at this time
looks like plan C, tomorrow....
thanks
OK, Kim. Review the notes in my first post on space allocation and best practices. Post again, if you have questions.
Hi,
I'm glad to report that reinstalling the app and specifying a larger number of devices during the install sized the database large enough that I could restore the database from the old location.
thanks Chris and Susan for your help and suggestions.
