Install and configure the D365 model

The model reads the database catalogue of your Dynamics 365 Finance and Operations environment — table names, row counts, and the space taken by data and indexes — and posts it to https://tsize.sims-service.com. It never reads the contents of a table.

On the portal the numbers become a dashboard: what grows, what is safe to clean, and — after a cleanup — how much space you recovered. You can also share the same numbers, anonymously, with engineers who bid on your cleanup job.

• An API key. Create a project in your client dashboard and copy the key shown when it is created. The full key is shown only once — see the Client guide if you have lost it.
• A D365 user with rights to run it. The model brings the security role Table size administrator (view the data, maintain the setup, run the processes). A system administrator can do all of it too.
• Outbound HTTPS from the server that runs the batch to https://tsize.sims-service.com, port 443.

SIMSTSizeBase is an X++ model built by SIMS Tech. It is not distributed through a public marketplace yet: write to vhlu@sims-service.com and we will send the package for your environment.

Deploy it like any other custom model: build, deploy the package, then run the database synchronization. Afterwards a Table size folder appears in three places under System administration — Inquiries (to look at the data), Periodic tasks (to run the collection) and Setup (parameters and table groups).

Open System administrationthenSetupthenTable sizethenTable size parameters and fill the fields below, then save.

Open System administrationthenPeriodic tasksthenTable size and run the three tasks in this order:

1. Update table registry. Refreshes the list of tracked tables and the total database size. Run it once now and again after you add modules.
2. Collect size snapshot. Measures the tracked tables and stores one row per table. In the dialog, Update mode is one of:
   • Yesterday only — refreshes the previous day; the recommended daily run.
   • Full recollection — re-measures every tracked table now. Use it for the first run.
   • Date range — re-measures the days you choose (From date, To date).
3. Send size snapshot to portal. Sends the most recent snapshot. In the dialog, Snapshot label says why it was taken:
   • Periodic — a routine measurement. Use this for your first test.
   • Before cleanup and After cleanup — send the first one just before you clean, the second right after. The portal pairs them and shows Space recovered.

When the send finishes, the infolog shows Snapshot chunk 1 of N sent, HTTP 200. Open your project on the portal — the tables appear within seconds. A large database is sent in several chunks of up to 2000 tables; the snapshot counts as complete when the last chunk is in.

Optional: the daily series

The daily series turns your measurements into one point per table per day. Days without a measurement are estimated between the two nearest real ones, and the portal draws those estimated stretches dashed so a guess is never shown as a measurement. To use it, set Send daily series to Yes in the parameters, then run Build daily size series (fields Rebuild from and Rebuild until; leave both empty to rebuild everything; Send to portal when finished sends it straight away) and, separately if you like, Send daily series to portal.

Each of these tasks is a standard D365 batch-capable dialog. In the dialog, open Run in the background, turn on Batch processing, and set a Recurrence.

A typical setup that needs no attention afterwards:

Leave an hour between them so the collection is finished before the send starts. Before and after a cleanup, run the send by hand with the matching label.

For every measured table, one row:

{
  "tableName": "BatchJobHistory",
  "recordCount": 1500000,
  "dataSizeMB": 245.5,
  "indexSizeMB": 89.2,
  "totalSizeMB": 334.7,
  "dataAgeMonths": 36
}

• tableName is the table name. A table outside the dbo schema is sent as schema.Table, so two tables with the same name in different schemas stay two tables.
• dataAgeMonths is the age of the oldest row, and is sent only for tables that have a creation date field.
• Never sent: the contents of any table, user or customer data, company names, server names.

Messages you will see while sending, and what they mean:

Still stuck? Write to vhlu@sims-service.com with the infolog text.