Note: This question is part of a series 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 the series.
Start of repeated scenario
You have a Microsoft SQL Server data warehouse instance that supports sever
al 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 added to the table over time, but the presence of these indexes slows data loading.
All tables are in a database named
DB1
. You have a second database named
DB2
that contains copies of production data for a development environment. The data warehouse has grown and the cost of storage has increased. Data older than one year is accessed inf
requently and is considered historical.
The following requirements must be met:
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 stra
tegy that is as granular as possible.
Partition the
Fact.Order
table and retain a total of seven years of data.
Partition the
Fact.Ticket
table and retain seven years of data. At the end of each month, the partition structure must apply a sliding window st
rategy to ensure that a new partition is available for the upcoming month, and that the oldest month of data is archived 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 s
torage costs while maintaining query performance for current data.
You are not permitted to make changes to the client applications.
End of repeated scenario
You need to implement the data partitioning strategy.
How should you partition the
Fact.Order
table?
A. Create 17,520 partitions.
B. Use a granularity of one day.
C. Use a granularity of one month.
D. Create 1,460 partitions.
Explanation:
We create on partition for each day, which means that a granularity of one day is used.
Note: If
we calculate the partitions that are needed, we get: 7 years times 365 days is 2,555. Make that 2,557 to provide for leap years.
From scenario: Partition the Fact.Order table and retain a total of seven years of data.
The Fact.Order table is optimized for
weekly reporting, but the company wants to change it to daily.
Maximize the performance during the data loading process for the Fact.Order partition.
Reference: https://docs.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-tables-partition