f1002d6e4a
Critical fix based on user analysis: PROBLEM: Cleanup is called in 2 contexts with different requirements: 1. BEFORE restore (from rman_restore): Should NOT shutdown 2. AFTER restore (from weekly-test): MUST shutdown to delete files USER INSIGHT: "Why shutdown if restore will clean anyway? But AFTER restore, you MUST shutdown to release file locks for deletion!" SOLUTION: Add /AFTER parameter to cleanup_database.ps1: WITHOUT /AFTER (before restore): - Skip SHUTDOWN ABORT - Skip Stop-Service - Leave service in current state (running/stopped) - Files CAN be deleted (no lock before restore) - Optimization: If service running → restore saves ~30s WITH /AFTER (after restore): - SHUTDOWN ABORT (stop instance) - Stop-Service (release file locks) - REQUIRED for file deletion after restore - Files are locked by active instance/service CALL SITES: 1. rman_restore: cleanup_database.ps1 /SILENT (no /AFTER) 2. weekly-test: cleanup_database.ps1 /SILENT /AFTER (with /AFTER) FLOW OPTIMIZATION: Test 1: Service stopped → start(30s) → restore → cleanup /AFTER Test 2: Service stopped → start(30s) → restore → cleanup /AFTER → No improvement yet BUT if we keep service running between tests: Test 1: Service stopped → start(30s) → restore → cleanup /AFTER Test 2: Service running → restore(0s saved!) → cleanup /AFTER → Save 30s on subsequent tests! Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>