Oracle database 19C moving back and forth with time without resetlogs [closed]

Question

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed last month.

Improve this question

my client have a oracle database 19C on windows server 2016 for a business reason he need to be able to move back in time to specific date/time and modify some data and then move forth to the current date with the same database using archive logs and without opening database with resetlogs

i did check flashback and point in time recovery and it always ends up opening the database with resetlogs

is it doable ? if there is some other way please share

Answer 1

I would say that this is an "X-Y Question" (Asking for one thing, "X", whilst actually wanting to achieve something else, "Y").
Mucking about, spinning the database back and forth "through time" is inherently dangerous and intrusive and, most likely, will not achieve what the client wants.
Being able to Flash-back and Flash-forward the database relies in all the changes involved being in the Database FlashBack Logs. As soon as you make changes to the "earlier" database, you cannot Flash it "forward" again without losing the changes you made "back then".

It's like every Time-Travel movie you've ever seen, where the villain goes back in time and changes something in the Past, thereby re-writing the Present. The only way to "rescue" the situation is to undo whenever they did (and that's basically what Flash-"forward" does).

Restate the [actual] problem.
What does the client actually want to achieve?

Databases accumulate data over time so if the client wants to change some "earlier" data, then they need to identify which data, what they want to do to it and then come and talk to you about the best way to do so (which shouldn't involve Database Recovery techniques, just regular insert/update/delete-type stuff).

And if, they've already tried that and something "in" the database actively prevented them from doing so, then there's probably a very Good Reason that it did so ...