問題タブ [partitioning]

ステージング テーブル (stage_enrolments) とプロダクション テーブル (enrolments) があります。ステージング テーブルはパーティション分割されていませんが、運用テーブルはパーティション分割されています。ALTER TABLE SWITCH ステートメントを使用して、ステージング テーブルのレコードを本番環境に転送しようとしています。

ALTER TABLE dbo.stage_enrolments SWITCH TO dbo.enrolments PARTITION @partition_num;

ただし、このステートメントを実行すると、次のエラーが発生します。

ALTER TABLE SWITCH ステートメントが失敗しました。ターゲット テーブル 'Academic.dbo.enrolments' は 1 つのインデックス付きビューによって参照されますが、ソース テーブル 'Academic.dbo.stage_enrolments' は 0 個の一致するインデックス付きビューによってのみ参照されます

登録に関するビューは分割されていますが、dbo.stage_enrolments で定義したのと同じインデックス付きビューを dbo.enrolments で定義しています。ビューとそのインデックスを再作成して、すべてのオプションが同じであることを確認しようとしましたが、同じ結果が得られました。dbo.enrolments ビューからインデックスを削除すると、正常に動作します。

インデックス付きビューを持つ別のテーブルのセットで動作しているため、これらで動作しない理由がわかりません。なぜこれが起こっているのかについて誰かが考えを持っていますか? 他に何をチェックすればよいですか？

シナリオ1000万行のテーブルがあります。10個のパーティションに分割します。これにより、パーティションあたり100万行になりますが、他には何もしません（パーティションを別のファイルグループやスピンドルに移動するなど）。

パフォーマンスは向上しますか？これは実際には、10個の小さなテーブルを作成するようなものですか？キールックアップまたはスキャンを実行するクエリがある場合、はるかに小さなテーブルに対して動作しているかのようにパフォーマンスが向上しますか？

パーティション化が、適切にインデックス付けされたテーブルを持つこととどのように異なるのか、そしてパフォーマンスを向上させるためにどこで使用できるのかを理解しようとしています。

古いデータ（パーティションの切り替えを使用）をプライマリテーブルから読み取り専用のアーカイブテーブルに移動するのがより良いシナリオでしょうか？

100万行のパーティションと900万行のパーティションを持つテーブルが（パフォーマンス的に）類似していて、900万行を別のテーブルに移動し、元のテーブルに100万行しか残していませんか？

データベースから毎日 200K の範囲のデータを削除する必要があります。私たちのアプリケーションは、Oracle DB と Hibernate ORM ツールを使用した Java/Java EE ベースです。

次のようなさまざまなオプションを検討しました

1. 休止状態のバッチ処理
2. ストアド プロシージャ
3. データベースのパーティショニング

当社の DBA は、データベースのパーティション化が最善の方法であると提案しているため、パーティション化されたテーブルを毎日簡単に再作成および削除できます。問題は、毎日削除したいデータと保持したいデータの 2 種類があることです。このデータがテーブル「Trade」に格納されているとします。パーティショニングにより、2 つのテーブル "Trade" ができました。DB との間で取引をフェッチ/保存するための既存の Hibernate ベースの DAO レイヤーがあります。データベースを分割することを決定した場合、休止状態を介して 2 つのテーブルのどちらに取引を行うかを制御するにはどうすればよいでしょうか。基本的に私が望むのは、その日の終わりまでに取引を削除し、パーティション化されたテーブルに移動し、保持したい取引をメインテーブルに入れる必要があるということです。これが Hibernate でどのように可能になるかを提案してください。

私たちが間違った道を進んでいる場合に備えて、誰かがより良いアプローチを提案できれば幸いです。

ユーザーからの投稿を保存するいくつかのフォーラムサーバー (それらが何であるかは関係ありません) があり、これらのサーバー間でリクエストを分割できるようにしたいと考えています。私は現在、地理的な場所でそれらを分割することに傾いています。データの局所性を向上させるために、ユーザーは北米、南米などの地域に分けられます。

パーティショニング プロパティをサーバーにマップする関数を実装する方法に関する設計パターンはありますか?

SQL Server 2008で大きなテーブル（〜100.000.000行）を使用しています。頻繁に、このテーブルとの間で〜30.000.000行のバッチを追加および削除する必要があります。現在、大きなバッチをテーブルにロードする前に、インデックスを無効にし、データを挿入してから、インデックスを再構築します。私はこれが最速のアプローチであると測定しました。

最近から、速度を上げるためにこのテーブルにテーブルパーティションを実装することを検討しています。バッチに従ってテーブルを分割します。

私の質問ですが、ある特定のパーティションのインデックスを無効にして、再度有効にする前にそのパーティションにデータをロードすることは可能ですか？その場合、テーブルの残りの部分でインデックスを完全に再構築する必要はなく、読み込みをさらに高速化できますか？

私はこれまで主キーに auto_generated または Sequences を常に使用してきました。私が取り組んでいる現在のシステムでは、最終的にデータを分割しなければならない可能性がありますが、これは過去には必要ありませんでした。将来的にデータを分割する必要があるかもしれないことを知っていますが、データベースの組み込みシーケンスの代わりに PK に UUID を使用する利点はありますか? もしそうなら、比較的短いキーを安全に生成できる設計パターンはありますか (通常の長いキーの代わりに 6 文字とします e6709870-5cbc-11df-a08a-0800200c9a66)? テーブルごとに 36^6 個のキーは、私が想像できるどのテーブルにも十分すぎるほどです。

URL でキーを使用するので、簡潔にすることが重要です。

数百万行のテーブルがあり、いくつかのパーティションを作成したいのですが、どうすればこれができるのか本当にわかりません。つまり、ID 1-> 10000で始まるデータをパーティション1に置き、ID10001->20000で始まるデータをパーティション2に置きたいということです。など...？その方法の例を教えていただけますか？

私はインターネットでたくさん検索し、たくさんのドキュメントを読みましたが、それがどのように行われる必要があるのか​​まだわかりません！

よろしくお願いします、

テーブル「X」があり、次のことを行いました

1. 値 (1、2、3、4) の左範囲としてパーティション関数 PF1(INT) を作成します。
2. パーティション スキーム PS1 をパーティション PF1 としてすべて作成 ([プライマリ])
3. PS1(col1) の X(col1) にクラスター化インデックス CIDX_X を作成します。

この 3 つの手順により、私が持っていたデータの 4 つの論理パーティションが作成されました。

私の質問は、このパーティショニングを元の状態に戻すにはどうすればよいですか?

衝突検出とさまざまな空間分割手法の関係を常に耳にします。物理ライブラリには、錐台クラスや、八分木や四分木などの実装を容易にするものなど、一般的なデータ構造が含まれていますか？

xセットに分割する必要があるn個の要素があり、各セットは正確にk = 4個の要素を保持する必要があります。

要素の各ペアが同じセットを 1 回だけ共有するという制約を使用して、考えられるすべてのパーティションを見つける必要があります。

したがって、[1 2 3 4] [5 6 7 8] [...] で開始すると、連続するすべてのパーティションが [1 2 XX] や [XX 1 3] などを保持することはできません。セットは順不同です。

この問題に近いのは、第 2 種スターリング数です。ただし、それらは任意のサイズのセットの問題のみを解決します。

例: 32 匹のマウスを 8 つのケージ (1 つのケージに 4 匹) に入れることができます。マウスは、別のマウスに 2 回会わないようにケージ間で回転させる必要があります。どのくらいの頻度でこれを行うことができますか?また、構成はどのようなものですか?