Analytics in App Store Connect receives its biggest update since its launch, including a refreshed user experience that makes it easier to measure the performance of your apps and games. Updates include:

• More than 100 new metrics. Now you can access monetization and subscription data in Analytics to better understand the performance of your In-App Purchases and offers.
• New cohort capabilities. Analyze user behavior based on common attributes — such as download date, download source, offer start date, and more — to measure how a particular group of users performs over time. For example, if you’ve expanded your app to a new region, you can monitor how long it takes users in that region to make a purchase compared to other more established regions. Cohort data is aggregated to ensure user privacy.
• New peer group benchmarks. Discover how you stack up to peers with two new monetization benchmarks: download-to-paid conversion and proceeds per download. Benchmarks incorporate differential privacy techniques to protect individual developer performance while also providing meaningful and actionable insights.
• Two new subscription reports. Export these via the Analytics Reports API to perform offline analysis and integrate Analytics into your own data systems.
• Additional filters. Apply up to seven filters to your selected metrics at once allowing you to drill down further and uncover additional insights.
• App Store Analytics Guide. This new guide in App Store Connect Help enables you to develop a data-driven strategy and understand App Store tools and features you can use to grow your business.

Learn about measuring performance with Analytics

Read the new Analytics guide

Every SQL Server instance contains a database that most people never query, never back up, and never even see in Object Explorer. Yet, without it, SQL Server would not start. Enter the SQL Server Resource database.

This article explains what the SQL Server Resource database is, why it exists, and how it affects patching, upgrades, and troubleshooting – without the mythology that often surrounds it.

What is the SQL Server Resource database?

The SQL Server Resource database is a hidden, read-only system database that contains:

Logically, these objects appear to live in the master database. Physically, they do not. Instead, they live in two files:

These files sit alongside the system databases, but they are not listed as a database in normal system views.

Why does the SQL Server Resource database even exist?

To understand why the SQL Server Resource database exists, it helps to understand what came before it.

Before SQL Server 2005

In SQL Server 2000 and earlier:

The master database was both:

That coupling caused real problems.

It was common – and still is – for users to create objects in the master database, because it’s the only place where code can be created and used by all databases. (I wish it was possible to create true libraries in SQL Server!)

The problem then, was that the upgrade/patching code needed to modify the master database couldn’t be sure of the state of that database – making it far more likely for updates to fail.

The Resource database was introduced in SQL Server 2005 to solve that very specific problem: to decouple system code from system configuration.

In practical terms:

The Resource database contains code, and the master contains instance state. This allows for a much cleaner separation.

What lives where in the SQL Server Resource database

The SQL Server Resource database contains:

When you run:

SELECT * FROM sys.objects;

SQL Server is reading metadata from the Resource database. Rather than metadata, the master database contains:

The master database references system objects; it does not own their definitions.

How does SQL Server use the Resource database?

At startup:

If the Resource database is missing or corrupted:

Why is the SQL Server Resource database read-only?

The Resource database is intentionally read-only.

This prevents:

It also ensures:

Allowing writes here would reintroduce the same fragility SQL Server had before 2005.

Patching and the SQL Server Resource database

When you apply a cumulative update or service pack:

This design is why:

Why don’t you back up the SQL Server Resource database?

You will often hear:

You don’t need to back up the Resource database.

That statement is correct – but incomplete. Backups of it aren’t useful because:

A backup does not provide a meaningful recovery path. Instead, you protect the Resource database indirectly by protecting:

If the Resource database is lost, recovery is reinstallation – not restore.

Common myths about the SQL Server Resource database

System objects live in master

Incorrect. They appear to live in master, but do not.

You can modify system procedures

You can override behavior in limited ways, but you cannot safely modify the underlying definitions.

Corruption in master affects system code

Usually, it does not. System code lives elsewhere.

The Resource database is optional

Incorrect. SQL Server cannot run without the Resource database.

How to view the SQL Server Resource database (carefully)

You can see the SQL Server Resource database files:

SELECT *
    FROM sys.database_files;

You can also attach a copy for inspection:

CREATE DATABASE resource_copy
    ON (FILENAME = '...\mssqlsystemresource.mdf')
    FOR ATTACH;

This should be done:

Why does understanding the SQL Server Resource database matter?

Understanding the SQL Server Resource database helps you:

The SQL Server Resource database: in summary

The SQL Server Resource database is invisible by design, but fundamental by necessity. It exists to make SQL Server:

The post Everything you should know about the SQL Server Resource database appeared first on Simple Talk.