A DBA is planning a major version upgrade of a production database engine that supports an order-processing application. Which sequence follows sound upgrade practice?
Select an answer to reveal the explanation.
Short Explanation
A major upgrade is surgery, not a haircut. You take a backup, practice on a copy, make sure the application still works, and keep a way back if it goes wrong. Going straight at production is the trap that bites people.
Full Explanation
Major version upgrades can change the on-disk format, deprecate features, alter optimizer behavior and change defaults, so they are planned as controlled changes. A verified backup protects against a failed or corrupting upgrade. Rehearsing in a non-production environment that mirrors production reveals upgrade duration, errors and performance changes. Compatibility checks, including running the application's tests and reviewing deprecated features, confirm the application still works. The production upgrade is then scheduled in an approved window with a documented rollback plan and validation steps. Upgrading production first uses customers as testers and leaves no rehearsed procedure if the upgrade fails. Choosing peak hours maximizes the number of users affected by downtime or defects, which no support availability can offset. Skipping the backup because old binaries remain is wrong by concept: binaries are not data, and a major upgrade often converts data files in a way the old version cannot read, so only a backup or restore point guarantees a path back. Exam caveat: some upgrades are one-way once data files are converted, which makes the pre-upgrade backup the real rollback plan. Operational check: restore the pre-upgrade backup to a test server and run the upgrade there end to end before scheduling production.