1
0
mirror of https://github.com/Microsoft/sql-server-samples.git synced 2025-12-08 14:58:54 +00:00
Files
sql-server-samples/samples/databases/wide-world-importers/wwi-ssdt
Jos de Bruijn efa54273da Wwi update (#257)
* wwi revision from Robert Cain

* added .sln files

* adding publish.xml files for ssdt projects

* correct DB names in publish.xml

* renaming project names to align with DB names

* removing redundant config procs from OLAP DB; adding version table

* moving full-text indexing to post-deployment script

* updated SampleVersion, and added version to post-deployment script

* aligning start date with v1 start date

* reduce rowcount to accomodate low-end systems

* fixing T-SQL syntax error

* fixing T-SQL syntax issue

* aligning naming of SSIS package with v1

* update RLS sample to work with v2 of wwi

City IDs are no longer hard-coded

* updating DB names for SSIS

* aligning publish name with DB name

* updating DB settings

* aligning DB name

* improved perf for coldroomtemperature

Improved process, such that all data for a given day is generated as a
single native proc execution, which accumulates the data in a
non-durable table. this data is then bulk-moved to the archive table,
before adding the most recent data to the current table.

* aligning names of memory_optimized_data filegroups

* updated filegroups in project files

* commenting ApplyPolyBased from post-deployment

deployment of the SSDT project should not fail if connection with the
Azure storage account cannot be established. Therefore, applying the
PolyBase piece to the sample DB is something the user needs to do after
deploying the DB.

* removing ApplyPolybase from post-deployment

* aligning DB set options

* cleaning up FTS artifacts

* aligning data source name

* facilitating publication to azure

- removing explicit filegroup references from index definitions
- adding snapshot hints to references for memory-optimized tables, to
facilicate publication in DBs without the
MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT hint

* initial updated docs for OLTP DB

* initial documentation for WideWorldsImportersDW

* docs for SSIS package

* initial documentation for SSASMD project

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* Update README.md

* adding Azure SQL DB sections to docs

* Update README.md

* Update README.md

* cleaning up local solution files

- cleaning up bad references in local solution files
- calling out SSAS and SSIS dependencies more explicitly in the READMEs

* replacing inner join to BuyingGroups with LEFT JOIN

Fixing logical error in the integration proc. Not all customers are in
buying groups.

* removing redundant reference to release

* correction around Azure deployment

* corrections around Azure deployment

* Update README.md

* Update README.md

* Update README.md

* clarified how 2012 data is generates

* Update README.md

* minor updates

* implementing PR comments

* Update README.md

* Update README.md

* clarifying VS2017 caveats

* adding caveat for VS2017

* caveat for VS2017

* removing stale file reference

* removing stale folder

* adding DB option to post-deployment scripts for Azure SQL DB purposes

* fixes for migration Azure SQL Premium->Standard

* fixes for enabling/disabling In-Memory OLTP

* renaming to avoid confusion

* aligning project structure with best practice - aligning SSAS DB name with others
2017-06-29 14:47:18 -07:00
..
2017-06-29 14:47:18 -07:00
2017-06-28 14:48:06 -07:00
2017-06-28 14:48:06 -07:00

WideWorldImporters OLTP Database

The Visual Studio SQL Server Data Tools project in this folder is used to construct the WideWorldImporters database from scratch on SQL Server or Azure SQL Database. It is possible to vary the data size.

A pre-created version of the database is available for download as part of the latest release of the sample: wide-world-importers-release.

Contents

About this sample
Before you begin
Run this sample
Disclaimers

About this sample

  1. Applies to: SQL Server 2016 (or higher), Azure SQL Database
  2. Key features: Core database features
  3. Workload: OLTP
  4. Programming Language: Transact-SQL
  5. Authors: Greg Low, Denzil Ribeiro, Jos de Bruijn, Robert Cain

The instructions below are for creating the sample database from scratch.

Before you begin

To run this sample, you need the following prerequisites.

Software prerequisites:

  1. SQL Server 2016 SP1 (or higher) or an Azure SQL Database (Premium). Also works with SQL Server 2016 RTM, for Evaluation, Developer, and Enterprise edition.
  2. Visual Studio 2015 Update (or higher) with SQL Server Data Tools (SSDT). We recommend you update to the latest available of SSDT from the Visual Studio Extensions and Updates feed.

Run this sample

The below steps reconstruct the WideWorldImporters database.

Note that each time the database is created from scratch, the data in many tables will be different as a degree of randomization is used throughout the code.

Publishing to SQL Server

  1. Open the solution wwi-ssdt.sln in Visual Studio. Skip this step if you have already opened the solution wwi-sample.sln in the root of this sample.

  2. Build the solution.

  3. Publish the WideWorldImporters database:

    1. In the Solution Explorer, right-click the WideWorldImporters project, and select Publish to bring up the Publish Database dialog.
    2. Click Edit to modify the Target Database Connection to point to your SQL Server 2016 (or later) instance.
    3. Edit the Database Name to say "WideWorldImporters".
    4. Click Publish.
    5. Wait for the publication process to finish. You can monitor progress in the Data Tools Operations page in Visual Studio. During testing this took around 3 minutes.
  4. (Optional) Data population: After step 3, the database contains data for January 2013. This step populates data from February 2013 up to the current data.

    1. Open SQL Server Management Studio, and connect to the WideWorldImporters database that was published in the previous step.
    2. Execute the following script. This may take a while to complete - populating data from Feb 2013 to Jun 2016 took about 40 minutes in one test on a machine with 3.4GHz CPU and the transaction log on SSD.
    EXEC DataLoadSimulation.PopulateDataToCurrentDate
    @AverageNumberOfCustomerOrdersPerDay = 60,
    @SaturdayPercentageOfNormalWorkDay = 25,
    @SundayPercentageOfNormalWorkDay = 0,
    @IsSilentMode = 0,
    @AreDatesPrinted = 1;

To customize the period for data generation, leverage the stored procedure DataLoadSimulation.DailyProcessToCreateHistory.

The referenced stored procedure removes the temporal nature of the tables, and implements a series of triggers. It then emulates typical activities that would occur during each day. Finally, it removes the triggers and re-establishes the temporal tables. You can see the progress of the simulation in the Messages tab in SSMS as the query executes. (AreDatesPrinted controls whether dates are printed to the messages window as data is generated. IsSilentMode controls whether detailed output is printed. IsSilentMode = 1 produces just date output if AreDatesPrinted = 1.). Note that a different outcome is produced each time it is run as it uses many random values. StartDate and EndDate cover the period for generation. The OLAP database WideWorldImportersDW contains the stored procedure Application.Configuration_PopulateLargeSaleTable to populate the 2012 period with a large amount of data for columnstore tables testing, so do not populate back into 2012 or earlier using the DailyProcessToCreateHistory procedure. The EndDate must also be at or before the current date as temporal tables do not allow future dates. You can configure the amount of data produced by modifying the number of orders per day. The default is 60 orders per day and produces a reasonable OLTP database size of around 160MB compressed for a period of 3.5 years - note that attaining this backup size requires shrinking the log after data generation. You are also able to configure how busy Saturday and Sunday are compared to normal Monday to Friday working days, as a percentage. The suggested values are 50% for Saturday and 0% for Sunday.

Publishing to Azure SQL Database

To publish the database to Azure SQL Database, complete the following steps after Step 1 in the previous section:

A. Update the partition schemes Storage\PS_TransactionDate.sql and Storage\PS_TransactionDateTime.sql as follows: replace every occurrence of USERDATA with PRIMARY.
B. Delete the filegroups Storage\USERDATA.sql and Storage\WWI_MemoryOptimized_Date.sql.
C. Right-click the project WideWorldImporters and select Properties to open the properties pane.
D. Change the Target Platform to Microsoft Azure SQL Database v12, and press Ctrl-S to save.
E. Create a new Azure SQL Database with the name WideWorldImporters. As pricing tier, select Premium. For instructions see: Create an Azure SQL database in the Azure portal.

Continue with Step 2 above.

Disclaimers

The code included in this sample is not intended to be used for production purposes.