クエリ ストアが読み取り専用状態に移行するのを回避するには、最後の古いクエリしきい値の日数の実行時統計が、定義された最大サイズ (MB) 内に収まる必要があります。統計収集間隔を増やすと、永続的な実行時統計に使用される領域が少なくなり、新しいデータ用の空き領域が増えます。データ フラッシュ間隔によって読み取り専用状態への移行を遅らせることはできますが、移行が発生する可能性を最小限に抑えることはできません。
参照：
https://docs.microsoft.com/en-us/sql/relational-databases/performance/best-practice-with-the-query-store

ファイルの数はマシン上の（論理）プロセッサの数に依存します。一般的なルールとして、
論理プロセッサの数が8以下の場合は、論理プロセッサと同じ数のデータファイルを使用します。論理プロセッサの数が8より大きい場合は、8つのデータファイルを使用し、競合が発生した場合は
引き続き発生する場合は、競合が許容レベルまで減少するまでデータ ファイルの数を 4 の倍数ずつ増やすか、ワークロード/コードを変更します。
参照：
https://docs.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database

セクション: [なし]
Explanation:
ステップ 1: マスター データベースで、CREATE LOGIN [App1] WITH PASSWORD = 'p@aaW0rd!' を実行します。ログインはサーバー全体のログインとパスワードのペアであり、ログインのパスワードはすべてのデータベースで同じです。
ログインを作成する Transact-SQL のサンプルを次に示します。
password='1231!#ASDF!a' でログイン readonlylogin を作成します。
CREATE LOGIN コマンドを実行するには、管理者ログイン (SQL Azure ポータルから取得) を使用して SQL Azure 上のマスター データベースに接続する必要があります。
ステップ2: DatabaseAで、CREATE USER [App1] FROM LOGIN [App1]を実行します。
ユーザーはデータベースごとに作成され、ログインに関連付けられます。ユーザーを作成するデータベースに接続する必要があります。ほとんどの場合、これはマスター データベースではありません。ユーザーを作成するサンプル Transact-SQL を次に示します。
ログイン readonlylogin からユーザー readonlyuser を作成します。
ステップ3: DatabaseAでALTER ROLE db_datareader ADD Member [App1]を実行します。
ユーザーを作成しただけでは、データベースへの権限は付与されません。アクセス権を付与する必要があります。以下の Transact-SQL の例では、readonlyuser に db_datareader ロールを介してデータベースへの読み取り専用権限が付与されています。
EXEC sp_addrolemember 'db_datareader'、'readonlyuser';
参照：
https://azure.microsoft.com/en-us/blog/adding-users-to-your-sql-azure-database/