Note: This question is part of a seri
es of questions that use the same scenario. For your convenience, the scenario is repeated in each question. Each question presents a different goal and answer choices, but the text of the scenario is exactly the same in each question in this series.
You
have a Microsoft SQL Server data warehouse instance that supports several client applications.
The data warehouse includes the following tables:
Dimension.SalesTerritory
,
Dimension.Customer
,
Dimension.Date
,
Fact.Ticket
, and
Fact.Order
. The
Dimension.SalesTerritory
and
Dimension.Customer
tables are frequently updated. The
Fact.Order
table is optimized for weekly reporting, but the company wants to change it to daily. The
Fact.Order
table is loaded by using an ETL process. Indexes have been ad
ded to the table over time, but the presence of these indexes slows data loading.
All data in the data warehouse is stored on a shared SAN. All tables are in a database named
DB1
. You have a second database named
DB2
that contains copies of production dat
a for a development environment. The data warehouse has grown and the cost of storage has increased. Data older than one year is accessed infrequently and is considered historical.
You have the following requirements:
Implement table partitioning to
improve the manageability of the data warehouse and to avoid the need to repopulate all transactional data each night. Use a partitioning strategy that is as granular as possible.
Partition the
Fact.Order
table and retain a total of seven years of data.
Pa
rtition the
Fact.Ticket
table and retain seven years of data. At the end of each month, the partition structure must apply a sliding window strategy to ensure that a new partition is available for the upcoming month, and that the oldest month of data is ar
chived and removed.
Optimize data loading for the
Dimension.SalesTerritory
,
Dimension.Customer
, and
Dimension.Date
tables.
Incrementally load all tables in the database and ensure that all incremental changes are processed.
Maximize the performance during
the data loading process for the
Fact.Order
partition.
Ensure that historical data remains online and available for querying.
Reduce ongoing storage costs while maintaining query performance for current data.
You are not permitted to make changes to the c
lient applications.
You need to optimize the storage for the data warehouse.
What change should you make?
A. Partition the
Fact.Order
table, and move historical data to new filegroups on lower-cost storage.
B. Create new tables on lower-cost storage, m
ove the historical data to the new tables, and then shrink the database.
C. Remove the historical data from the database to leave available space for new data.
D. Move historical data to new tables on lower-cost storage.
Explanation:
Create the
load staging table in the same filegroup as the partition you are loading.
Create the unload staging table in the same filegroup as the partition you are deleting.
From scenario: Data older than one year is accessed infrequently and is considered historic
al.
References: https://blogs.msdn.microsoft.com/sqlcat/2013/09/16/top-10-best-practices-for-building-a-large-scale-relational-data-warehouse/