Stat Environment Refresh

I believe there are two main goals of the Refresh CSR. One is to document the source, date and reason for the refresh. The second is to ensure that after the refresh, all state based reporting for the target environment is correct. Thus in your example, the state based reporting after the refresh will reflect all of the objects migrated to env2 prior to the refresh date. So the one specific CSR is just for those purposes and the other object specific CSRs are are documented for the activity based reporting where those object were originally migrated.
Does that help?

I understand how documenting the refreshes is useful, especially for state based reporting. What confuses me is why a refresh would be tied to a CSR. I guess you would create a CSR specifically for the purpose of recording a refresh, but then none of the CSR fields or workflow steps apply because a refresh is outside of any of our CSR workflows. Should we create a specific CSR Type and workflow just for the purposes of recording refreshes?

I would be curious in the thoughts of other customers as there may be many ideas here. From my point of view, I always thought a specific CSR type was appropriate as the workflow would be unique and the approvals would be very special. While their could be deviations between environments, i.e. PROD-> Dev might be very different from PROD->Training from an approval point of view or even from a frequency point of view. I also think the approvals would be different as the impact of a refresh may be much greater than one team or area. Creating this workflow wouldn't be that major of a task but would allow a more specific and typically shorter process for approval.

The documentation in regards to environment refreshes is not all that great. This is a hot topic for us right now and I would be interested in finding the current "best practice" in regards to managing environment refreshes using STAT.

The attached document is old so some features may have changed slightly, but should still be mostly accurate.  I hope this helps with the steps.  As for best practices, I will look for others to provide their thoughts.

stat_environment_refresh.pdf

The document Jeff provided is still relevant. The short answer is best practice is to use environment refresh CSRs. Refreshing environments without all stakeholders knowing an environment was refreshed could impact user testing as well as lead to environments being out of sync. As a former Stat user, I also used Environment refreshes to manage the refresh process and make sure it had the appropriate approvals and notifications to all stake holders before the refresh was scheduled and appropriate validation and testing was performed after the refresh before it was released to users. Environment refreshes can be expensive and create significant workload for the dba team. The are necessary but the process, resources, state, and impacts must be managed.

Hi JSenn,
Attached is an updated quick start guide on DB Refresh CSR's you may find helpful.

4375.Stat Intro to DB Refresh Tracking.pdf