A nightly data-cleanup script currently runs from a DBA's workstation and fails whenever that laptop is shut down or the DBA is logged out. The cleanup must run every night unattended. What is the best change?
Select an answer to reveal the explanation.
Short Explanation
A job that depends on your laptop being awake is a job that depends on luck. Move it to the server side, where a scheduler runs it on time whether you're there or not. The trap is the workaround answers that keep the workstation in the picture.
Full Explanation
Where a script runs determines what it depends on. A client-side script on a workstation needs that machine powered on, the user session active and the network path available, so any of those failing stops the job. Running the cleanup as a server-side job, through the database engine's own job scheduler or an operating system scheduler on a server, ties it to infrastructure that is monitored, stays up and can run under a dedicated service account with only the permissions it needs. Server-side jobs also centralize logging and alerting on job success or failure. Keeping the workstation awake and logged in is a fragile workaround that still breaks with reboots, updates or lost network connections, and it leaves an unattended logged-in session, which is a security concern. Converting the cleanup into client-side code that runs when users open the application ties maintenance to user activity, so it may run many times a day or not at all, and it pushes database maintenance into every client. An open IDE session is an interactive tool, not a scheduler, and has the same workstation dependency as the current setup. Exam caveat: server-side scheduling still requires failure notifications; a silent failed job is no better than a missed one. Operational check: create the scheduled job, run it once on demand, then confirm the next night's run appears in the job history with a success status and an alert configured for failures.