Luminis 3.3.3 to 4 calendar migration issues
Hello,
We're trying a dry run migration of Luminis 3.3.3 to Luminis 4. We managed to export the platform and calendar data (Result 0 Errors, 0 Warnings).
When importing the data, the platform data imported, but we're having problems with the calendar data import.
After a while, the calander data import locks up, with no more output to the log file. I had a look in the cs5migrate.log file and saw errors like this:
[17/Nov/2009:13:45:15 +0000] suffix-luminis cs5migrate[19621]: General Error: caldb: Error with calendar database: DB_ENV->log_flush: LSN of 1502/9154494 past current end-of-log of 1/17834
[17/Nov/2009:13:45:15 +0000] suffix-luminis cs5migrate[19621]: General Error: caldb: Error with calendar database: Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment
Sungard support have suggested that I should re-build the Luminis 3.3.3 database, then do the export again.
This is a real pain for us, as we need downtime to do the export which annoys our management somewhat. I think Sungard should have least suggested this in the Migration documentation before the export, as it would save us having to do the export again.
Before I rebuild the Calendar database and run the export again, has anyone else hit this issue during migration?
Any advice much appreciated!
Regards,
Paul Hughes
Bangor University, Wales, UK
I agree with support
We did not hit this in our migration, but I think I agree with support, it does look like a DB problem.
We hit a different import issue on migration:
To fix this we installed Sun patch 125818-09 prior to importing the calendar. Note the README for this patch says to add the install path path. We also had to change ownership after patching
As far as the production down time is concerned, for conversion testing, we cloned the calendar and portal boxes so that we could re-export as often as we needed during regular hours. (it does not need network connectivity for the export.) I would highly recommend this if there is any way you can do it. In our case, we were booting off the SAN and mirroring already for DR so it was easy. In the new setup we are using VMware so it is equally easy.
Update
Thanks for the info. At least I can look out for that problem as well!
Oddly enough, I ran the csdb check command on the exported calendar database files and it responded with:
Checking the database health condition.
Please be patient, this may take a while...
Start by scanning components db...
Scanning events database...
1064437 events scanned
1064437 events copied
Scanning todos database...
9282 todos scanned
9282 todos copied
Successful components db scan
Now starting calprops db scan...
Scanning calprops database to uncover events...
42338 calendars scanned
Scanning calprops database to uncover todos...
finished...
Calendar database consistency check completed successfully
Which suggests (and also confirmed by support) that the calendar database files are fine. I'll probably re-build the database just in case and try again.
Regards,
Paul
Hope rebuilding helps
if you google "LSN past current end-of-log" this is clearly a Berkely DB corruption issue, even though the csdb check did not find anything I would still try the rebuild.
Good luck,
John
re csdb rebuild
I had sun software support tell me once that it is often useful to run csdb rebuild multiple times back to back. I don't know how knowledgeable that sun engineer was, or if that is recommended under all conditions.
He made it sound as if csdb repairing, say, error 1, upon running a second time, would reveal error 2.
Thanks guys, That's good
Thanks guys,
That's good advice. I'll try a couple of rebuilds on our exported calendar files and try the import again.
I've read in a few other places that the csdb check doesn't always pick up all the errors, which seems a bit pointless!
Many thanks,
Paul