It's all about the answers!

Ask a question

How to Sync TST env with PRD via SQLserver logging?

long TRUONG (3654121147) | asked May 17 '16, 1:25 a.m.
edited May 17 '16, 1:31 a.m.
 At our site: RTC (WI only)/RRC 5.0.2 Windows/Tomcat.

We are still reeling with pending re-indexing after huge WI imports brought CLM to its knee every 2 or 3 hrs (post 220347). Even though we have added memory to the max 32GB allowed by Windows Server 2008 to resolve the issue, we still have some OOM hangs with same pending re-indexing active service (by ADMIN) for much smaller imports, when we have to resort again to a skew heap allocation, against the 50/50 rule of thumb, of Xmx24G/8GBleft2OS to resolve.

We are looking at sync'ing our TST env to PRD, so these imports can be tested first in TST. Our TST env has been sync'ed to PRD occasionally via DB cloning, with a rather long process plus the 8-hr minimum full re-indexing. We are hoping that SQLserver logging replay will give us faster and probably feasible to automate sync's.

We have two major questions:
- Is there a way for us to use TST side logging to back track to last PRD logging replay? So that if an import tests successfully on TST, we will be able to turn the state back to before the test (with the test import activities and any other ones, since last replay, wiped out), and we can sync again with PRD logging replay of the real successful import (+other activities since previous PRD logging)
- We have been using HostsSpoofing to use the same PRD public URI on TST to avoid a "server rename" of the PRD-cloned DB's at each DB refresh. Can we get out of spoofing with a one-time "server rename" on TST? i.e. Is the SQLserver logging free of the PRD public URI (dumb to think so?) or if the logging can be modified to be free of the PRD public URI?

Be the first one to answer this question!

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.