When performing a Point In Time Restore to the _same_ environment, the batch jobs remain enabled, and start uncontrollable, immediately after the restore - the batch jobs are not started in restoring from a different environment.

We request to disable (withhold) the batch jobs for same-environment PITR operations - just like they're already disabled for any other type of database movement.

Business case - it has actually happened in one of our large customer's Sandbox environment:

A user created a batch job at 8am on Monday, and scheduled to run at 10pm on Monday.

We found it on Tuesday, that the job caused some data issues, so we decided to do a Point-In-Time restore to the status before the job started: 9pm Monday.

We had a successful restore on Tuesday, but as soon as the system started after the restore, the batch scheduler found the above batch job scheduled to 10pm Monday, so started it immediately -> we ended up with the same database issue with no options to disable the job.

Finally, we had to do another Point-In-Time restore to the status of 7am on Monday - losing a whole day of testing.