タグ付けされた質問 「filegroups」

2
read_onlyファイルグループの列ストアインデックスによりCheckDBが妨げられる
ファイルグループに列ストアインデックスが含まれている場合、データベース全体をread_only防止するようdbcc checkdbにファイルグループを設定しているようです。実行しようとするcheckdbかcheckfilegroup(のための任意の読み書きセカンダリとを含め、データベース内のファイルグループ[PRIMARY])、以下のエラーが返されます... Msg 8921, Level 16, State 1, Line 24 Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors. 読み取り専用のファイルグループに列ストアデータを保持するためのサポートされている方法はありますか?または、このシナリオの整合性チェックから除外されますか? 再現 create database check_fg_ro go use check_fg_ro go exec sp_changedbowner 'sa'; go alter database check_fg_ro add …

1
主キーをファイルグループに移動する(SQL Server 2012)
クラスター化された主キーを新しいファイルグループに移動するにはどうすればよいですか?私はすでに可能な「アルゴリズム」を見つけましたが、恐ろしく非効率的です: クラスター化されていないインデックス付きのドロップ(それらを再ソートして再構築する必要があります) クラスター化インデックスを削除します(テーブル全体を再ソートする必要があります) 新しい主キー制約を作成します(巨大なソート操作) すべての非クラスター化インデックスを作成する(並べ替えと書き込みが必要) より効率的な方法はありますか?これはひどく非効率的であり、弱いサーバーではテーブルのサイズが50GBであるため、時間がかかります。 これらすべてをスキップして、新しいファイルグループで再構築する方法はありませんか?データの並べ替えは必要ありません。

2
複数のファイルのファイルグループに割り当て単位を含む正確なファイルを特定する方法はありますか?
どのデータベースファイルに、データベース内に存在するさまざまなHoBT(アラインされたものとアラインされていないもの)のどの割り当てユニットが含まれているかについて、詳細なビューを取得したいと考えていました。 ファイルグループごとに複数のデータファイルの作成を開始するまで、私が常に使用してきたクエリ(以下を参照)は役立ちました。 select SchemaName = sh.name, TableName = t.name, IndexName = i.name, PartitionNumber = p.partition_number, IndexID = i.index_id, IndexDataspaceID = i.data_space_id, AllocUnitDataspaceID = au.data_space_id, PartitionRows = p.rows from sys.allocation_units au join sys.partitions p on au.container_id = p.partition_id join sys.indexes i on i.object_id = p.object_id and i.index_id = p.index_id join sys.tables …

1
ファイルグループの利点とファイルグループを読み取り専用に設定
複数のファイルグループを読み取り専用に変更するのが適切なオプションであり、それらをいつ使用するべきかについて、誰かが実際のシナリオを引用してくれませんか?読み取り専用に設定するとどのようなメリットがありますか? 複数のファイルグループを持つデータベースでは、データベース全体のバックアップを実行し、そのファイルグループの各ファイルもバックアップする必要がありますか。ファイルグループバックアップが使用される場合の例も教えてください。データベース全体をバックアップできるのに、ファイルグループをバックアップすることが有益である理由はわかりません。このファイルグループのバックアップが理想的な実世界での体験が得られることを願っています

3
SQL Server:システムテーブルのみのファイルグループ?
私たちの企業標準の1つは、ユーザーテーブル/インデックス用に個別のファイルグループ/ファイルを用意することです。これはデフォルトとして設定されているため、CREATE TABLEステートメントを修飾する必要はありません。 だからこんな感じ fileid 1 =システムテーブル、MDF fileid 2 = t-log = LDF fileid 3 =ユーザーのもの= NDF なぜこれが義務付けられたのか、元の正当性を理解するのを手伝ってくれる人はいますか? 私はそれがブードゥー教だと思う状態できれいに来ます。私は間違っていますか...? 編集:インデックス/パーティション/アーカイブを分離するためにファイルグループを使用する方法と、断片的に復元する方法を知っています。この質問は、システムテーブル専用の同じボリューム上の別のファイルグループの使用についてです。

2
単一のファイルグループでのパーティション分割
データベースに非常に大きなテーブルがいくつかありますが、このデータのかなりの部分が「古い」ものです。 私の制御が及ばない状況のため、この「古い」データを削除することは許可されていません。その他の制限は、データベースを変更できないことです。つまり、データベースにファイルグループを追加できます。現在の状態では、すべてがPRIMARYファイルグループに存在しています。 これらのテーブルを「新しい」、「古い」、「アーカイブ」などのいくつかのパーティションに分割することを考えていました。この目的で使用したい「ステータス」列があります。 説明されているシナリオと制限を考えると、パーティション分割がここで意味をなすかどうか疑問に思っていました。つまり、テーブルがこのようにパーティション化されているが、すべてのパーティションが同じファイルグループにある場合、SQL Serverは、「新しい」データが存在する基になるファイル内の特別な領域を見つけるのに十分スマートであり、 「古い」データのあるエリア? 言い換えると、私のデータの80%が「古い」としましょう。SQL Serverには、基になるファイルの100%へのアクセスを回避し、「新しい」データを含む20%のみにアクセスするメカニズムがありますか(もちろん、WHEREクエリの句でパーティション列を指定するとします)。 私はこれに答えると思います、パーティションが内部でどのように実装されているかを理解する必要があります。私はどんなポインタにも感謝します。


2
ファイルが関連付けられていないファイルグループは削除できません
SQL Server 2017 CU3で奇妙なエラーメッセージが発生します。データベースを移行し、ファイルグループを再編成しています。「再編成」とは、オブジェクトの新しいファイルグループにパーティション関数とパーティション構成を作成し、パーティション分割中にインデックスを再構築してからパーティション分割を削除するストアドプロシージャを使用することを意味します。 最後に、いくつかの空のファイルグループを取得しました。それらのファイルは削除されます。また、ファイルグループ自体も削除されます。これはほとんどの場合うまくいきます。ただし、2つのデータベースの場合、ファイルを削除しました... 関連付けられているファイルがないままファイルグループが残っていますが ALTER DATABASE REMOVE FILEGROUP エラー5042をスローします。 ファイルグループ 'xyz'は空ではないため削除できません。 質問 空のファイルグループを削除するにはどうすればよいですか? 私はすでにいくつかの一般的な問題を読みましたが、それらは私のシステムにはありません: チェック済み: SELECT * FROM sys.partition_schemes; SELECT * FROM sys.partition_functions; 0行...データベースにパーティションオブジェクトが残っていません UPDATE STATISTICS データベース内のすべてのオブジェクト 無効 ファイルグループのインデックスをチェックします。 SELECT * FROM sys.data_spaces ds INNER JOIN sys.indexes i ON ds.data_space_id = i.data_space_id WHERE ds.name = 'xyz' 0行 ファイルグループ内のオブジェクトを確認します。 …

1
SQL Serverは読み取り専用ファイルグループのレコードを更新しましたか?
データウェアハウスに非常に大規模なデータベースがあり、メンテナンスとバックアップを管理するためにパーティションを実装しています。特定の期間のレコードは、最終的には月に1回、読み取り専用ファイルグループに移行されます。 時々、私たちのETLプロセスはすでにアーカイブに移行された古いレコードを更新しようとしますが、これらは失敗すると予想されます。ただし、テスト環境のレコードが読み取り専用ファイルグループのパーティションにあるように見える場合でも、テストのレコードが更新される最近の例が少なくとも2つあります(クエリsys.partition_functionsとsys.partition_range_values)。 本番環境で同一のレコードを使用すると、レコードを更新しようとしたときに予期したエラーが発生します。これまでに2回これをキャッチしましたが、更新は本番環境では失敗しますが、テストでは成功します(その逆はありません)。 関連する環境の事実: SQL Server 2012 SP3 CU3(ビルド11.0.6537.0) テストは開発者版、製品はエンタープライズ版 リクエストに応じて他のユーザーに提供できます:現在深刻な困惑しています... 更新2016-08-19 新しいレコードがどういうわけか一晩で更新されました。読み取り専用ファイルグループ上にあることを確認しました。同時に挿入された(つまり、読み取り専用ファイルグループの同じパーティションにもある)レコードを更新できることがわかりました。同じパーティションで単一のレコードを識別し、そのレコードを複数回更新できました。夜間に更新されたレコードを更新しようとすると、予期した障害が発生します。 更新2016-08-11 更新は、読み取り専用パーティションでのテストの夜間処理中にも発生し続けます。プロセスから同じレコードを更新しようとすると失敗します。以前にそれを更新したユーザーとしてログインしたときに、同じレコードを更新しようとして失敗しました。私はまた、毎晩のプロセスでまだ触れられていない同様のレコードを更新して問題を再現することはできません。 更新2016-08-04 同じパーティションスキームを使用して、別のテーブルで同じ動作の別の発生を発見したため、その単一のテーブルに限定されないことを今日発見しました。 更新2016-08-03 このMSDNスクリプトからスクリプトを実行すると、Kendra Littleのパーティションヘルパービューを使用したときに得られる結果ph.FilegroupDetailとph.ObjectDetail、このデモから確認できます。問題のレコードはパーティション#2にあります(問題のレコードのパーティション列の値は2015-03-18です) Filegroup Low Boundary UpperBoundary Archive (RO) NULL 1900-01-01 Archive (RO) 1900-01-01 2015-04-01 ActiveFG (RW) 2015-04-01 2015-07-01 ActiveFG (RW) 2015-07-01 2015-10-01 ActiveFG (RW) 2015-10-01 2015-01-01 ActiveFG (RW) 2016-01-01 2016-04-01 ActiveFG (RW) …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.