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

私は、テーブルを分割した場合ntext、textまたはimageデータ型とを備えた単一パーティション上のインデックスを再構築しonline = off、それは、テーブル全体または問題のちょうどパーティションをロックしていますか？

9 sql-server  sql-server-2016  partitioning 

以下の挿入トリガーがあるパーティションビューがあります（貧弱なパーティション）。DELETEを実行すると、以下のクエリプランが表示されます。 delete from factproductprice where pricedate = '20170725' ビューのトリガー： ALTER TRIGGER [dbo].[factProductPriceDelete] ON [dbo].[FactProductPrice] INSTEAD OF DELETE AS BEGIN IF @@ROWCOUNT = 0 RETURN; DECLARE @PriceDate DATE SELECT @PriceDate = CAST(PriceDate AS DATE) FROM DELETED IF @PriceDate BETWEEN '20140101' AND '20141231' BEGIN DELETE FROM dbo.FactProductPrice2014 WHERE ProductId IN (SELECT ProductId …

9 sql-server  sql-server-2014  trigger  partitioning  execution-plan 

：私の環境は以下である VMWareの5.5活発化サーバーMS Windows Serverの2008R2エンタープライズドメインおよびSQL Server 2008 R2のエンタープライズ。ファイバーチャネル接続による集中型ストレージ。 にパーティションがありますSQL Server DB。2 file groupsつあります。1つはライブデータ（FG1）、2つ目は履歴データ（HDG）です。 2番目のファイルグループはread-onlyです。毎月パーティションで移動を行います-（前月の）新しいデータを履歴データに追加します。このプロセスは自動です。 データベースを新しいサーバーに移動しました。最初は、手動でプロセスを実行する必要がありました。この操作中に、次のエラーでミラーが故障します（操作3の後-以下のプロセスフローを参照）。 プリンシパルサーバー： ログの行0： Date 15.6.2015 20:54:11 Log SQL Server (Current - 16.6.2015 07:55:00) Source spid84 Message Setting database option MULTI_USER to ON for database MYDB. ログの行1： Date 15.6.2015 20:54:11 Log SQL Server (Current - 16.6.2015 07:55:00) Source …

9 sql-server  partitioning  mirroring  vmware 

大規模なパーティションOLAPテーブルを管理する特権があります。この表を確認したところ、インデックスの1つがパーティションスキームと一致していないことに気付きました。著者が利用できず、注意深く作成されたGoogle検索で有用な結果が返されなかったため、これが意図的なものか偶発的なものかはわかりません。 SQL Server 2008でインデックスをパーティションアラインしない理由はありますか？

9 sql-server  sql-server-2008  index  partitioning 

以下のコードは次のことを行います： C：\ TEMPにデータベースplay_partitionを作成します 2つの同一のパーティション分割テーブルplay_tableおよびarchive_play_tableを作成します play_tableパーティション1をarchive_play_tableパーティション1に切り替えます play_tableパーティション2と同じファイルグループに、play_tableと同じ構造の新しいパーティション分割されていないテーブルtemp_tableを作成します。 play_table_partition 2をtemp_tableに切り替えます temp_tableをplay_tableパーティション2に戻そうとし、失敗します メッセージ4982、レベル16、状態1、行64のALTER TABLE SWITCHステートメントが失敗しました。ソーステーブル 'play_partition.dbo.temp_table'の制約をチェックすると、ターゲットテーブル 'play_partition.dbo.play_table'のパーティション2で定義された範囲では許可されない値が許可されます。 なぜ失敗するのですか？ SQL Server 2014（Enterprise Edition Trial）を使用しています。 よろしく、 コリン・デイリー http://www.colindaley.com/translator /* Playing with partitioned tables */ USE master; GO DROP DATABASE play_partition; GO CREATE DATABASE play_partition ON PRIMARY( NAME = play_partition , FILENAME = 'C:\TEMP\play_partition.mdf') ,FILEGROUP play_fg1( …

9 sql-server  partitioning  sql-server-2014 

数日前にgoogle onegramをダウンロードしましたが、すでに大量のデータがあります。10個のパッケージの最初のパッケージをmysqlに挿入すると、4700万個のレコードデータベースができました。 どのようにしてGoogle ngramをデータベースに最適に保存すればよいのでしょうか。つまり、1グラムを使用していない場合、たとえば2グラムや3グラムを使用すると、量ははるかに多くなります。1つのデータベースに5億のレコードを保存して使用できますか、それとも別のテーブルに分割する必要がありますか？ いくつのレコードを分割する必要があり、どのように最適に分割する必要がありますか（2グラムには100個のファイルがあり、したがって約50億のレコードがあると考えます）。MySQLの水平パーティションを使用するか、独自のパーティションを構築することをお勧めしますか（たとえば、wordの最初の文字=> twograms_aを使用）。

9 partitioning 

パーティション分割を使用して、ロックのためにOLTPシステムエクスペリエンスがブロックされる量を減らし、パーティションIDに基づいて作業テーブルを100個のパーティションに分割します。ただし、テスト中に、実行プランが予想したとおりに選択されていないことがわかりました。 テストシナリオは、300,000件の連絡先レコード（各連絡先のデータは2つのテーブルに分割されています）を持つ単一の顧客であり、すべて単一のパーティションに存在し、顧客のパーティションで500の特定の行を検索するクエリがあります。ハッシュ一致のようなものが計画のかなり早い段階で不要な299,500を排除することを期待しますが、SQL Serverはテーブル全体のレコード数を取得し、すべてのパーティションで平均化することを選択しているようです。処理する多くのレコード。これにより、ネストされたループが選択され、プロセスのかなり後の方で不要なレコードが削除されます。通常、これには、パーティション分割されていないテーブルに対する同じクエリの9倍の時間がかかります。 奇妙なことに、selectにオプション（再コンパイル）を追加すると賢明な計画が得られますが、なぜこれが違いを生むのか途方に暮れています。これはストアドプロシージャではありません。テスト中に、各テストを実行する前にプロシージャキャッシュをクリアします。 この動作は、関係するテーブルが分割されていない場合には見られません。つまり、推定される行数が実際の数と一致するため、毎回適切なプランが選択されます。 この動作についての洞察はいただければ幸いです。 スキーマのセットアップ： USE [Scratch] GO CREATE SCHEMA part GO CREATE PARTITION FUNCTION [ContactPartition](smallint) AS RANGE LEFT FOR VALUES (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, …

9 sql-server  sql-server-2012  partitioning  execution-plan 

セットアップ 〜115,382,254行の巨大なテーブルがあります。テーブルは比較的単純で、アプリケーションプロセスの操作を記録します。 CREATE TABLE [data].[OperationData]( [SourceDeciveID] [bigint] NOT NULL, [FileSource] [nvarchar](256) NOT NULL, [Size] [bigint] NULL, [Begin] [datetime2](7) NULL, [End] [datetime2](7) NOT NULL, [Date] AS (isnull(CONVERT([date],[End]),CONVERT([date],'19000101',(112)))) PERSISTED NOT NULL, [DataSetCount] [bigint] NULL, [Result] [int] NULL, [Error] [nvarchar](max) NULL, [Status] [int] NULL, CONSTRAINT [PK_OperationData] PRIMARY KEY CLUSTERED ( [SourceDeviceID] ASC, [FileSource] …

8 sql-server  index  partitioning  azure-sql-database 

SQL Server 2008 Enterprise EditionをSQL Server 2016 Standard Editionにアップグレードしたい。ただし、1つのデータベースは、複数のファイルグループにまたがるテーブルパーティションを使用します（大きなログテーブルで使用され、毎日がパーティションです）。 私はで見るSQL Serverの2016年のためのエディションとサポートされる機能、それはスタンダード版がサポートしていることを言うことは、「RDBMSスケーラビリティとパフォーマンス」の下にテーブルとインデックスのパーティションを、それがないではないサポートするパーティション表の並列処理を。 私がこれの結果を完全に理解しているかどうかはわかりません。 私の場合、それは正確に何を意味し、データベースのパフォーマンスにどのように影響しますか？

8 sql-server  partitioning  sql-server-2016 

データウェアハウスに非常に大規模なデータベースがあり、メンテナンスとバックアップを管理するためにパーティションを実装しています。特定の期間のレコードは、最終的には月に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) …

8 sql-server  partitioning  filegroups 

SO、外部ブログ投稿、マニュアルに関するいくつかの質問をすでに読んだことがある SO：Pgのパーティションテーブルへの外部キー制約 dba.SE：PgのパーティションテーブルへのFKのさまざまな処理方法 マニュアル：継承 マニュアル：パーティショニング 手動：制約トリガー ブログ：継承によるPostgresモデリング それでも、自分のケースを考慮してパーティション分割を行うべきかどうか疑問に思っています。 ケース-簡略化 顧客データの保存。下記の表の名前はすべて、わかりやすくするために作成されています。 顧客によって識別可能で非物理的な存在であるオブジェクト、およびオンデマンドで顧客にオブジェクトを送り返す必要がある場合にオブジェクトが実際に格納される物理オブジェクト、または他の方法でオブジェクトを処理する。それらは多対多の関係でマッピングされます。objects_nonphysical、objects_physical、objects_mapping_table。 2番目の多対多の関係は、これらの非物理オブジェクトとそのメトリックの間です。いくつかのメトリックにバインドされているオブジェクトがあります。metrics、metrics_objects_nonphysical 非物理オブジェクトと物理オブジェクトの両方に、子と親の関係である階層テーブルがあります。objects_nonphysical_hierarchy、objects_physical_hierarchy 各顧客のニーズと要件に応じて、物理オブジェクトに関するデータを提供することも、ゼロから作成する必要がある場合もあります。基本的に、私がする必要があるのは： 高速のための社内体制の維持INSERTおよびSELECTマッピングが場所を取るために起こっているのはここであるため、ステートメントを。 外部顧客が非物理オブジェクトを表示および操作できるようにシステムを維持します -データの高速検索。ステートメントの効率に対する強いニーズSELECT -このデータは、多くの顧客がいつでも検索できるようになっています。 私の配慮 データにアクセスし、データを表示して操作する顧客がいる可能性がありますが、それは、データを取得したり、データを処理している請負業者である必要はありません。 これにより、システムにテーブルパーティション分割を導入し、どのパーティションデータが該当するか（請負業者のパーティション分割）を常に把握していることを考慮し、次に、顧客のパーティション分割が必要な外部顧客向けのメインテナンスシステムに進みました。（これは、自動化ツールと一連のルールを使用して顧客の方法でデータを書き換えるのを遅らせるため、顧客ごとにテーブルごとに1つのパーティションのみをスキャンします。 データ量 特に新しい顧客のオブジェクトとメトリックをインポートする場合、私のデータは常に増加します。システムに到着する新しいデータのペースは、長期的に見て現時点では予測できません。誰が次の顧客になるかがわからない場合、実際に測定する方法はありません。現在、2つの顧客があり、各テーブルのすべての顧客に対して100万行が多かれ少なかれあります。しかし、将来的には、新規顧客の数が1,000万人になると予測しています行程度になるています。 ご質問 これらの質問はすべて互いに関連しています。 ここでパーティショニングを本当に考慮すべきですか、それとも過剰ですか？私は常に正確に1つをスキャンしているので、それは役に立つと考えていますパーティションを。 パーティショニングがFK最適な方法である場合、自分のニーズを考慮して最も効果的に制約を適用するにはどうすればよいですか？私は行くべきconstraint triggersですか、それとも内部システムのアプリケーション層に保つべきですか、それとも他の方法でしょうか？ パーティショニングがうまくいかない場合、何に飛び込むべきですか？ 十分なデータが提供されていない場合は、下のコメントでお知らせください。

8 postgresql  performance  partitioning  postgresql-9.4