Over the past couple months I have heard conflicting information on when to run the DM Regen. Some people have said that they lock the DB then run the regen, some have said its fine to run mid day on production. Some have said doing it while many users were on caused data validity issues and orphaned records.
We are running 10.1.500.11 and the ICE Customization Guide doesn’t say anything about running it off hours or any warnings about data errors. It simply states do the regen and recycle the app pool. Is this really fine to run at any time now? I assume the previous problems people had were 10.0 or even 10.1.400 (pre sync and regen combine).
This is just my opinion, but I would never run a regen on production unless during a maintenance window. I also prefer to stop the app server before running it and start when complete. I have never experienced an issue this way.
It’s true in the E10.0 days it was much more finicky and prone to issues before the process was combined. However, like Dan, I’d not recommend running mid-day during production if you can avoid it.
I’ve done it “live” on our test server with patch 10.1.600.x when I knew users were testing the system just to see what would happen. It worked fine but I never tried it with .500 series. Again, this was a test server not our production server.
The best practice is to do this during a maintenance window.
If you delve into what is happening under the covers technically, you might be able to sneak it in during the day if you have perfect awareness of what is happening on your system and can make the change and not affect any running processes but that’s a tightrope most (including myself) don’t like to attempt.
The reality is that you are probably doing this in tandem with another change of functionality that you want to deploy changes to clients. You add a UD field for a reason - not to sit there and take DB space. You probably have a BPM, a new customization, a new dashboard - something that you want to push out to folks so you want them to log out to get the new Order Entry form or the like.
Doing this in dev? That’s another conversation. I hack around constantly and am changes things on the fly as I do things. Test and Live? Nah, I am not that brave. Something will be missed. Plan the change and rolling it out in production in a formal process is a better habit
Running it on our test and development systems we have not run across any issues. In our development system we regen multiple times a day with multiple people in system.
But LIVE/Production is too important to take a chance, I agree with others that you should only do it in a maintenance window. And as mentioned by others without a recycle and/or other deployments the regen isn’t going to make any visible change to the users.
The data model regeneration requires that users are not in the system–ideally, with the appserver processes stopped before the regen is started to guarantee that users are not in the system.
Please plan a time after hours when there aren’t users in the system for the data model regeneration, and the subsequent recycle of all appservers connected to that database.
