1Cのニーズに合わせたSQLサービス計画の作成：Enterprise 8.x

1C：Enterpriseで使用されるsql-baseのサービスの計画を立てる方法を指示する別の要求の後、私は自分の経験を一度に全員と共有することにしました。

なぜこれが必要なのか-SQLでデータベースを保守しないと、その意味は完全に失われます。 主なツールはインデックスであり、最新の状態に保つ必要があります。 私は1Cのコースではなく、実際に、ネテで、または1C自体のコースで教義に出会ったことがなかったので、私の経験を共有します。



多くの場合、ベースは「通常の」状態で動作します。 これが意味するもの：

• SQLサーバーには十分な供給があります。 SQLサーバーの操作に提供されるRAMの量は、すべてのmdfデータベースファイルのサイズの70％の計算から選択する必要があります。
• プロセッサは、90％の時間で50％を超えてロードされません。
• 十分なディスク容量があります（特にtemp.dbデータベースはソートに使用され、1Cは一般的にそのデータベースを使用しているため、事前にこのデータベースのディスク容量に注意する必要があります）。
• データベースリカバリモードは「シンプル」です。 （経験的に、大きなldfファイルは1秒遅くなり、ログファイルから回復する機能は非常に疑わしいことがわかっています）。

また、いくつかのニュアンスを考慮する価値があります。

• SQLのStandard Editionを使用し、インデックスを完全に再構築すると、すべてのユーザーがデータベースから切断されます。そのため、毎週のメンテナンスプランを決定する際にこれを考慮する必要があります（プランについては以下で説明します）。
• 特にシンクライアントまたはWebサービスが使用される場合、1Cサーバーもメモリを消費することを考慮する価値があります。
• SQL自体がサーバーパラメータのRAMの最大量を制限することをお勧めします。これにより、クリティカルマスに達すると、事前にRAMから不要なデータを消去し始めます。 そして、サーバー全体をst迷に追い込まないため。

通常の条件下では、2 週間 （1週間に1回）と1週間（残りの6日間）のサービスプランを使用するのが合理的です。

毎週

サービスプランの項目：

1. インデックスを再構築します。 タスクの意味は、既存のインデックスをすべて削除し、新しいインデックスをインストールすることです。 （大まかに言えば、すべての在庫と順序の整理）。
   
   パラメーターとして：
   
   
   • ターゲットベースの選択（これは、ほぼすべてのタスクで行われます。このパラメーターについては、この記事に注意を払わないためです）。
   • 「テーブルとビュー」を選択するオブジェクト。
   • 空き容量オプション-ハードディスク容量が少ない場合、「デフォルト」オプションを選択できますが、「ページの空き容量の割合を変更する」を使用することをお勧めします。推奨値は20％です。 これにより、空きページが確保され、インデックスを最新の状態に保つことができます。 注意：データベースのサイズが大きくなります。
   • tempdbで結果を並べ替えます。 説明する必要はないと思いますが、この時点でtempdbは非常に大きくなりますが、ソートはプロセスを高速化するように設計されていますが、注意してください、スペースに余裕があります。
   • インデックスをオンラインに保つことは、エンタープライズバージョンのSQLで利用できる機能です。 クライアントを切断せずにインデックスの再作成を許可します。
   !!! 注意!!! 標準バージョンでは、インデックスの再作成時に、この手順の間クライアントはデータベースから切断されます。
   設定例

   

   
   
   
   
   
2. 統計の更新。 データベース内のインデックスのステータスに関する情報を収集するタスク。 （一般的に、インデックスの再作成後に少し関連がありますが、それでも私は行います）。
   
   パラメータ：
   
   
   • オブジェクト。 インデックスの再構築と同じすべてのテーブルとビュー。
   • リフレッシュ。 ここで、すべての統計を更新します。
   • ビュータイプ-フルビュー。
   したがって、データベース全体の統計を更新します。
   設定例

   

   
   
   
   
   
3. T-SQLステートメントの実行。 これは任意のSQLコマンドの実行です。特に、私たちが興味を持っているのは

   dbcc proccache
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   名前が示すように、キャッシュのクリーンアップ。
   例

   

   
   
   
   
   
4. データベースの整合性を確認します。 ここでは不必要な説明のようです-何も壊れていないことを確信しています。 チェックの「インデックスを含める」パラメータでは、それらが再構築されることは無駄ではありませんでした。
   設定例

   

   
   
   
   
   
5. データベースのバックアップ。 ここでは、多くの機能があるため、さらに話す必要があります。 他のマニュアルでこの項目を自分で個別に調査することをお勧めします。この記事の形式では、バックアップの詳細な調査は行いません。
   
   しかし、私はいくつかのニュアンスについて警告したい：
   
   
   • SQLは、コンテナをクリーンアップする方法を知りません。ファイルにバックアップを追加すると（「バックアップデバイス」とも呼ばれます）、最終的にすべての空き領域を忘れてしまうためです。
   • SQLはバックアップを記憶しているため、ハンドルを使用して1回だけバックアップを作成した（たとえば、データベースを別の場所に移動したり、バックアップから別のテスト用に展開したり）と、次の「差異」がカウントされます。 これを防ぐには、「バックアップのみ」ボックスをチェックする必要があります。 バックアップタスクにはそのような項目はありません。 一般に、毎週の計画では、完全なタイプのバックアップを使用することをお勧めします。
   • そして、コピーを確認して、彼がよりよく眠れるようにするといいでしょう。
   • 一般に、圧縮を使用できますが、注意してください。その場合、差分圧縮も圧縮する必要があります。
   設定例

   

   
   
   
   
   
6. ログのクリーニング。
   
   
   • バックアップおよび回復ログ。
   • SQL Serverエージェントジョブログ
   • サービスプランログ。
   私はすべてをきれいにします。 名前が示すように、SQLログのイベントをクリーンアップします。 問題がある場合は1か月以内に報告してください。
   設定例

   

   
   
   
   
   
7. オペレーター通知。 独立した研究のために再び流行。 しかし、その名前が示すように、計画の実施中に問題を報告すること。

毎日

別々に話すのは意味がありません。 ほとんどすべてがウィークリーに似ています。

最初のタスクの違いは「インデックスの再編成」です。 タスクは、再編成が既存のインデックスをまっすぐにしようとする点で異なり、最初からすべてを実行するわけではありません。 断片化が多いほど、実行コストが高くなります。 ただし、通常の状態では、次の再構築までインデックスを最新の状態に保つには1日1回で十分です。 差分バックアップを使用することもできます。



以上です。 繰り返しますが、私はこの瞬間に教義を見ませんでした。このオプションは私によって開発され、テストされました。 6〜100 GBのサイズのデータ​​ベースの実際。



迅速で信頼できる仕事をお祈りします。

PS私は本格的なDBAではないため、おそらく私のコメントは非常に表面的なものであるため、コメントとPMのコメントを喜んで読みます。