Data replication in the real world
Problem: Staging System Unavailable
“When we go through the process of doing a full system copy of our
Production database, our testing and staging environments are unavailable
to continue our day-to-day activities. So we have to push our technical
people to work on the weekends, and if something happens in the midst of
it all and we run into a problem, we have to start over. So, the time outlay
and the costs go up.”
Solution:
Since SelectRefresh for SAP doesn’t perform a full database copy, the replication process is fast and does not require the system to be taken down. (Optionally, though, you can always do a full database copy if you want.)
Problem: Security Concerns
“To refresh our staging system, I have to wipe out all my data security,
and I’ve also got to put productive data in the testing environment.
It’s often HR or financial data, so there are security concerns.”
Solution:
SelectRefresh offers a data masking option for sensitive or confidential information such as employee IDs, account information, addresses, etc. Since the product only moves business data, data security tables are not affected.
Problem: Data Structure Inconsistent
“As far as my experience with data refresh tools goes, it has not
been pleasant. A fresh restore of an entire database takes work and usually
is fine; the system is generally usable after the project. However, trying
to restore only pieces of data relevant to sales orders or deliveries, etc.,
has never worked properly. The links between documents sometimes don’t
work, we have number-range conflicts between target and source systems,
there are inconsistencies of workflow procedures in the Production versus
Development system … these factors have all contributed to my recommendation
that we not do that sort of data transfer.”
Solution:
With SelectRefresh AutoDiscovery technology, all relationships between fields and tables are maintained perfectly. Your Target database is structured exactly the same as the Source. All links and document numbers will exactly match in the transfer from Source to Target. You can rest assured that SelectRefresh is accurate and safe.
Problem: Storage Maxed Out
“I used a product that did not deliver the ability to import data
into a Dev system without huge amounts of fallout that ultimately required
a full restore. After that, we added the functionality of building a data
mirror that could refresh data in hours after testing. That worked for the
most part but required an enormous amount of storage and we stopped using
it. Before that, we used another product that worked just “okay.”
It had many limitations like flooding the transport system on the box, and
no active monitoring tools to ensure proper order of transports or linking
of data types. The number ranges killed that product, because they were
always in error in the Dev system."
Solution:
SelectRefresh doesn’t require “an enormous amount of storage,” as the product that you used did. The target thin-client that is created is only a fraction of the size of full Production. Since the actual amount of data that is being transported is relatively small and can be throttled to work within your system resource constraints, the transport system will not be overloaded.
Problem: System Downtime
“It takes us about five days to get a test system up and running.
During that time, business is without a Q/A system. How do you move changes
into your Production system if you have no Q/A system? Projects always run
on a tight timeline – we get three days to create a test system. Project
teams are always upset with us. The failure rate is high. I’d say
we have a 50 percent hit rate—50 percent of the time we meet our commitments,
50 percent we don’t. Not good."
Solution:
SelectRefresh doesn’t require that you to bring the system down. Refreshes take hours, not days. That means your Quality Assurance system won’t be taken down.
