Hi Scott,
1. SCR introduces the concept of multiple database copies. What is meant by that?
2. Only database headers of SCR copies are updated, & SCR target would inspect source logfiles for permitting them to be truncated after being backed up by supported utilities. What is meant by only db headers being updated, & why not complete files? What is actually been ispected & where does it keep the files which is not committed into target, but has got inspected upon for deletion on source.
3. When performing data portability by restore-storagegroupcopy on target sg, if source is available, this command would copy the remaining log files from source to target, if any. But, in case the scr source is not available or lost forever, then what? Is there any dumpster concept here?
4. Why do we intend to make sure that the logfiles are copied, when we also would like to leverage the replay lag feature in case the logfiles are corrupted in the source & we dont like to get that corruption been replicated?
5. Let's say i mentioned a replay delay of say 5 hours & say i lost my scr source. Now, as per 5 hours delay in replay, it would get replayed after 5 hours gap. But where would they reside until they are replayed into scr target.
6. How can i stop the logfiles to be replayed into scr target after i found that scr source site is lost. Moreover, how would i get to know that whether the logfiles which are yet to be replayed into the scr target, are corrupted or not?
*****************************************************