問題タブ [log-shipping]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
sql-server - ログ配布：なぜリカバリなしモードを選択するのですか？
SQL ServerのLogShippingを構成するときに、セカンダリデータベースをリカバリなしモードまたはスタンバイモードにすることを選択できます。リカバリなしとは、ログ配布が行われている間はデータベースにアクセスできないことを意味します。スタンバイでは読み取り専用アクセスが可能であり、復元が行われるたびにユーザーを切断するオプションを選択した場合、ログ配布プロセスに干渉しないように見えます。これは私にはスタンバイモードの追加の利点のように見えますが、私が見る限り、ドキュメントには悪影響はありません。
したがって、なぜ誰もが回復なしモードを使用することを選択するのだろうかと思います。私が考えることができる唯一のもっともらしい理由は、スタンバイモードが大幅なパフォーマンスの低下を引き起こした場合（ただし、ドキュメントにはそのようなことは記載されていません）、またはセカンダリデータベースのコンテンツが誰にも見られないようにするためのセキュリティ要件がある場合です（これはまれに見える/ありそうもない）。
回復なしモードを選択することの利点が何であるかを誰かに教えてもらえますか？
sql-server - システム テーブルにトリガーを配置して、履歴データを収集するにはどうすればよいですか?
ユーザー定義テーブルにはトリガーを実装できますが、システム テーブルには実装できません (log_shipping_primariesおよび)。バックアップファイルが生成されたとき、およびトランザクション ログ シップ ファイルファイルがコピーされ、セカンダリ データベースに復元されたlog_shipping_secondariesときに関する情報が格納されます。.bak.trn
目標: セカンダリ データベース (DR サイト) で 15 分を超える RPO (目標復旧時点) を実装する
log_shipping activities私は、履歴データを監視し、上級管理職に提供する任務を与えられました。問題は、これらの 2 つのテーブルが、新しいエントリが追加されるたびに (特定のデータベースの) 古いエントリを更新することです。
解決策 (SQL Server 2000 では機能しません): 新しいエントリが挿入されるたびに、トリガーを介して同様のデータをユーザー定義テーブルに挿入し、履歴データを保持します。
- システムテーブルにトリガーを実装する方法(必要な権限)またはそれはまったく可能ですか(正確にしてください)?
- ストアドプロシージャなどのトリガーの代替（私はストアドプロシージャの経験がありません）
sql-server - ローカルの本番 SQL Server データベースからリモートの読み取り専用 SQL Server データベースにデータをコピーする
現在のセットアップが何であるかを説明することから始めて、それが必要な場所に進みます。
現在、CMS 用のローカル SQL Server データベースがあります。データベースはサイト上の他のサーバーから更新され、Web サイトに表示される製品情報を更新し、CMS 情報は MVC アプリケーションから更新されます。
今後は、ローカル データベースと同一の SQL Server データベースを備えたリモート サーバーが必要になります。このデータベースは、リモートの場所から更新されることはありません。
この問題は、ローカル データベースからリモート サーバーにデータを同期する方法を設計しようとしたときに発生します。SQL Server Enterprise にはこの場合に役立つ機能があることは知っていますが、現時点ではライセンスを持っていません。
私たちが思いついた最善のアイデアは、リモート サーバーにログを送信し、送信されたログを受信しているデータベースから復元を作成web.configし、新しく復元されたデータベースを指すように Web サイトを更新することです。これは機能する可能性がありますが、複雑すぎるように思われ、データベース名が絶えず変化するという問題があります。
誰かがより良い/より単純な解決策や現在のアイデアをより良くする方法を考えることができれば、それは大歓迎です.
不明な点がある場合、またはさらに情報が必要な場合はお知らせください。
logging - Logstash: GROK により「スレッド ウォッチドッグ タイムアウト」が発生する
ログを解析して別のサーバーに送信するようにlogstashをセットアップしようとしています。GROK がログの解析に失敗するたびに、次のエラーが発生します。
パターン ZEND_LOG は次のとおりです。
これにより、logstash エージェントが数分ごとにクラッシュし、ほとんど使用できなくなります。私は JIRA に提出された多くの既存のバグを見てきましたが、うまくいきませんでした。ここにいくつかのリンクがあります：
https://logstash.jira.com/browse/LOGSTASH-508
sql - 別のネットワーク内のリモートサーバーへのSQLサーバーログの配布
ディザスタ リカバリをセットアップする必要があります。同じネットワークにないリモート サーバーへのログ配布をセットアップする必要があります。ログ配布のtrcファイルをインターネット経由でリモートマシンに転送できます。ただし、trc ファイルをセカンダリ サーバーにインポートする方法。実際、データベースのバックアップ コピーのためにリモート サーバーにログシップしようとしています。
sql-server - ログ配布 - 高 IO および 30GB MSDB
約 6 か月間、いくつかのデータベースをログ配布してきましたが、現在のサイズは 20 ～ 60 GB です。ログは 5 分ごとに配布され、保持期間は 3 日間です。これらのログは、5 分ごとに約 18KB から 5MB まで変化します (小さい方が多くなります)。
MSDBData データベースが非常に大きくなっていることに気付きました (30GB)。これは正常ですか？
先日、(テスト) ログ配布データベースを削除するようになったとき、一見ログ配布履歴を削除しようとしている間に、30 分以上かかりました。ログ配布タスクを有効にすると、非常に高い IO が発生するようになりました。
sp_cleanup_log_shipping_history を実行してみました。これをスケジュールする必要があるのか、それとも自動的に実行するのか (?) は明確ではありませんが、数時間大量の IO が発生しましたが、MSDB のサイズは減少しませんでした (ディスクで使用される物理スペースではなく、テーブル サイズを調べます)。いくつかの行が削除されたようです。
私の知る限り、ログ配布にかかる時間は主に、問題を引き起こしているこの SP への呼び出しです。
現在、log_shipping_monitor_error_detail テーブルには 15293932 行があり、log_shipping_monitor_history_detail には 15350276 行があります。エラーは、後でログを削除する権限が不十分であったことが原因でした。
これをさらに診断する方法、「通常の」動作はどうあるべきか、これを再び発生させるためのメンテナンス タスクとして何をスクリプト化できるかについて、誰か提案はありますか?
(これがここに投稿されたものか、ServerFault に投稿されたものかはわかりませんが、ログ配布に関する質問が他にもありました!)
sharepoint-2010 - SP 2010 ログ配布の構成
私はウェブを検索しましたが、この種の質問に対する答えはほとんどまたはまったく見つかりませんでした...
新しいディザスタ リカバリ サーバーをセットアップしており、サーバーの準備は万端です。一時的な DBA が SQL DR サーバーへのログ配布をセットアップし、スタンバイ/読み取り専用ではなく回復なしを選択していたことを発見しました。
読み取り専用状態のコンテンツ データベースにアタッチできるようにしたいと考えています。これを行うには、設定を No Recovery から Stand By に変更する必要があります。この変更を行うための特別なプロセスはありますか、それとも同じくらい簡単で、設定を変更すればすべて完了しますか?
SQL Server 2008 R2 を使用しています。
ありがとう！
Matt Engel SharePoint 管理者
sql - 読み取り操作用のデータベースの SQL Server フル コピー
私の問題により適したものをアドバイスしてください。SQL サーバーがホストされているのと同じサーバーで高負荷の Web アプリをホストしています。また、同じサーバーで SQL サービス レポートを実行して、ユーザー レポートを生成しています。
したがって、私のサーバーは基本的にディスクの読み取り/書き込み速度の上で動作します。別のサーバーを取得し、そこに別の SQL サーバーをインストールして、そこで SSRS をホストします。したがって、私の基準は、できるだけ新しいデータを取得することです。
私はいくつかの解決策を見てきましたが、現在、ジョブを介してバックアップを作成し、それを2番目のサーバーにコピーして、ジョブを介してそこに復元しています。しかし、それは最善の解決策ではありません。
すべてのレプリケーション メカニズム (トランザクション、マージ、スナップショット) は、テーブルをロックすることでパブリッシャー データベースに影響を与えます。
それで、メインのデータベースに影響を与えずに定期的に同期される、読み取り専用アクセスでレプリカを作成する可能性はあるのだろうか? すべてのレポートの負荷をそのレプリカに置き、プライマリ データベースを Web アプリだけが使用するようにします。
私の問題に適した解決策は何ですか? 私は DBA ではないので、その方向性の調査を開始します。ありがとう。