You need to ensure that the transactional database is restored

You administer a Microsoft SQL Server 2012 server that hosts a transactional database and
a reporting database. The transactional database is updated through a web application and
is operational throughout the day. The reporting database is only updated from the
transactional database.
The recovery model and backup schedule are configured as shown in the following table:

At 16:20 hours, you discover that pages 17, 137, and 205 on one of the database files are
corrupted on the transactional database. You need to ensure that the transactional database
is restored. You also need to ensure that data loss is minimal.
What should you do?

A.
Perform a partial restore.

B.
Restore the latest full backup, and restore the latest differential backup. Then, restore
each log backup taken before the time of failure from the most recent differential backup.

C.
Perform a point-in-time restore.

D.
Restore the latest full backup.

E.
Restore the latest full backup, and restore the latest differential backup. Then, restore the
latest log backup.

F.
Perform a page restore.

G.
Restore the latest full backup. Then, restore each differential backup taken before the
time of failure from the most recent full backup.

H.
Restore the latest full backup. Then, restore the latest differential backup.

Explanation:
Requirements for Restoring Pages
A page restore is subject to the following requirements:
• The databases must be using the full or bulk-logged recovery model. Some issues
exist if you are using the bulk-logged model. For more information, see the following section.

• Pages in read-only filegroups cannot be restored. Trying to make a filegroup readonly will fail if there is a page restore going on at the same time in the filegroup.
• The restore sequence must start with a full, file, or filegroup backup.
• A page restore requires an unbroken chain of log backups up to the current log file,
and they must all be applied so that the page is brought up to date with the current log file.
• As in a file-restore sequence, in each restore step, you can add more pages to the
roll forward set.
• A database backup and page restore cannot be run at the same time.
Bulk-logged Recovery Model and Page Restore
For a database that uses the bulk-logged recovery model, page restore has the following
additional conditions:
• Backing up while filegroup or page data is offline is problematic for bulk-logged data,
because the offline data is not recorded in the log. Any offline page can prevent backing up
the log. In this cases, consider using
• DBCC REPAIR, because this might cause less data loss than restoring to the most
recent backup.
• If a log backup of a bulk-logged database encounters a bad page, it fails unless
WITH
• CONTINUE_AFTER_ERROR is specified.
• Page restore generally does not work with bulk-logged recovery.
• A best practice for performing page restore is to set the database to the full recovery
model, and try a log backup. If the log backup works, you can continue with the page
restore. If the log backup fails, you either have to lose work since the previous log backup or
you have to try running DBCC must be run with the REPAIR_ALLOW_DATA_LOSS option.