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

Postgresには7,801,611行の2.2 GBのテーブルがあります。uuid / guid列を追加していますが、その列にデータを入力する最良の方法は何ですか（NOT NULL制約を追加したいので）。 Postgresを正しく理解している場合、更新は技術的には削除と挿入であるため、これは基本的に2.2 gbテーブル全体を再構築しています。また、スレーブが実行されているため、遅れることを望みません。 時間をかけてゆっくりと入力するスクリプトを書くよりも良い方法はありますか？

33 postgresql  storage  ddl 

2つの未加工、つまりフォーマットされていないパーティションを使用してデータベースを作成しようとしています。 Microsoft Docsでは、これを実行できると述べています。次のように、rawパーティションのドライブ文字のみを指定するだけです。 CREATE DATABASE DirectDevice ON (NAME = DirectDevice_system, FILENAME = 'S:') LOG ON (NAME = DirectDevice_log, FILENAME = 'T:') ただし、SQL Server 2017は次のエラーを返します。 メッセージ5170、レベル16、状態4、行1 ファイル 'S：'は既に存在するため作成できません。ファイルパスまたはファイル名を変更して、操作を再試行してください。 メッセージ1802、レベル16、状態4、行1 CREATE DATABASEが失敗しました。リストされている一部のファイル名を作成できませんでした。関連するエラーを確認してください。 ドキュメントの適切な部分には次のように記載されています。 ファイルがrawパーティションにある場合、os_file_nameは既存のrawパーティションのドライブ文字のみを指定する必要があります。各rawパーティションに作成できるデータファイルは1つだけです。 そして、はい、ドライブS：とT：はどちらも私のシステムに存在する未フォーマットのrawパーティションです： DISKPART>詳細パーティション パーティション4 タイプ：ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 非表示：いいえ 必須：いいえ 属性：0000000000000000 バイト単位のオフセット：999934656512 ボリューム### LtrラベルFsタイプサイズステータス情報 ---------- --- ----------- ----- ---------- ------- ---- ----- …

16 sql-server  storage 

実稼働SQL Serverには、次の構成があります。 3台のDell PowerEdge R630サーバーを可用性グループに統合3台すべてがRAIDアレイである単一のDell SANストレージユニットに接続されている 時々、PRIMARYで次のようなメッセージが表示されます。 SQL Serverは、データベースID 8 のファイル[F：\ Data \ MyDatabase.mdf]で完了するのに15秒以上かかるI / O要求が11回発生しました。OSファイルハンドルは0x0000000000001FBCです。 最新の長いI / Oのオフセットは0x000004295d0000です。 長いI / Oの継続時間は37397ミリ秒です。 パフォーマンストラブルシューティングの初心者です ストレージに関連するこの特定の問題のトラブルシューティングで最も一般的な方法またはベストプラクティスは何ですか？このようなメッセージの根本原因を絞り込むには、どのパフォーマンスカウンター、ツール、モニター、アプリなどを使用する必要がありますか？役立つ可能性のある拡張イベント、または何らかの種類の監査/ログがありますか？

16 performance  performance-tuning  sql-server-2017  storage 

実稼働データベースに525 GBのサイズのテーブルがあり、そのうち383 GBは未使用です。 このスペースの一部を回収したいのですが、実稼働DBをいじる前に、より少ないデータでテストDBの同一のテーブルでいくつかの戦略をテストしています。この表には同様の問題があります。 テーブルに関するいくつかの情報： フィルファクターは0に設定されます 約30列あります 列の1つはイメージタイプのLOBであり、数KBから数百MBのサイズのファイルを格納しています テーブルには仮想インデックスが関連付けられていません サーバーは、SQL Server 2017（RTM-GDR）（KB4505224）-14.0.2027.2（X64）を実行しています。データベースはSIMPLE復旧モデルを使用しています。 私が試したいくつかのこと： インデックスの再構築：ALTER INDEX ALL ON dbo.MyTable REBUILD。これによる影響はごくわずかです。 インデックスの再編成：ALTER INDEX ALL ON dbo.MyTable REORGANIZE WITH(LOB_COMPACTION = ON)。これによる影響はごくわずかです。 LOB列を別のテーブルにコピーし、列をドロップし、列を再作成し、データをコピーしました（この記事で概説したように、未使用スペースのSQL Serverテーブルの解放）。これにより、未使用のスペースが減少しましたが、使用済みのスペースに変換するだけのようです。 bcpユーティリティを使用して、テーブルをエクスポート、切り捨て、再読み込みします（この投稿で説明されているように、テーブルの未使用スペースを解放する方法）。これにより、未使用スペースが削減され、使用済みスペースが上のイメージと同程度に増加しました。 推奨されていませんが、DBCC SHRINKFILEおよびDBCC SHRINKDATABASEコマンドを試してみましたが、これらは未使用の領域に影響を与えませんでした。 実行DBCC CLEANTABLE('myDB', 'dbo.myTable')しても違いはありませんでした 画像とテキストのデータ型を維持しながら、データ型をvarbinary（max）とvarchar（max）に変更した後、上記のすべてを試しました。 新しいデータベースの新しいテーブルにデータをインポートしようとしましたが、これも未使用スペースを使用済みスペースに変換するだけでした。この投稿でこの試みの詳細を概説しました。 これらが期待できる結果である場合、実稼働DBでこれらの試行を行いたくないので、 これらの試行のいくつかの後、未使用スペースが使用済みスペースに変換されるのはなぜですか？私は内部で何が起こっているのかよく理解していないように感じます。 使用済みスペースを増やすことなく、未使用スペースを減らすためにできることは他にありますか？ 編集：テーブルのディスク使用量レポートとスクリプトは次のとおりです。 SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON …

15 sql-server  index  sql-server-2017  storage 

PostgreSQLのドキュメントでは、整数データ型は2バイト、4バイト、または8バイトのスペースに格納できると言われています。データベース内のテーブルの列の1つに1バイトの整数値が含まれていて、それを1バイトのデータ型で格納したい。 PostgreSQLで1バイト整数データ型を使用する拡張機能または方法はありますか？ NUMERIC（1,0）は何バイトですか？

14 datatypes  storage  postgresql-9.6 

私は、2億4000万行の非常に頻繁に更新されるテーブルを持っています（そして成長しています）。3時間ごとに150万行が挿入され、150万行が削除されます。クラスターをSSDに移動すると、この一括挿入（コピーを使用）時間は22分から2.3分に短縮されました。削除時間も改善されました。この一括更新は2時間ごとまたは1時間ごとに行う予定です。 現在のパフォーマンス（SSD後）は、より頻繁な更新と互換性がありますが、書き込みの増幅と組み合わされたNANDの耐久性の限界によるSSDの死に関するいくつかの恐ろしい話を読みました。SSDは高価なので、可能な限り将来的にその死を押し上げたいと思います。したがって、私の質問：削除とその後のバキュームでディスクファイルは実際にどうなりますか？私は2つのディスク書き込みがあると思います。1つは行を削除済みとしてマークし、もう1つはバキュームして上書き可能としてマークします。削除とバキュームを行う代わりに、一括挿入/削除のたびにテーブルを作成および削除するテーブルをパーティション分割すると、SSDの摩耗を最小限に抑えることができますか？

13 postgresql  partitioning  delete  storage  vacuum 

以前のシニアDBAは、会社全体のすべてのSQL Serverのすべてのドライブにマウントポイントを設定しました。新しいシニアDBA は、マウントポイントが私たちの標準を変更したいので怖がっています（主に、経験がないためだと思います）。 多数のインターネット検索の結果に基づいて、マウントポイントを使用しない理由（SQL Server 2000以降）が見つかりません。 このトピックに関するWindows OSの制限を知っている人はいますか？ 最近、「OSはマウントポイントを認識しない」という主張をよく耳にします。（私たちが使用しているWindows Serverのバージョンに関する私の調査に基づいて、真実ではありません）。 SQL Serverでマウントポイントを使用しない証拠または経験に基づいた理由はありますか？ ドライブ文字の不足は問題ではないと仮定します。 マウントポイントは、ワークロードの分離に非常に役立つことを理解しています。 マウントポイントは、データファイル、ログファイル、およびtempdbの各ドライブよりも効率的に、さまざまな種類のデータおよびログファイル（システムデータベースファイル、ユーザーデータベースファイル、tempDB）のワークロードを実際に分離/分離するという理解を確認または反論できますか？ ？

12 sql-server  storage  architecture  mount-point 

たとえば、それぞれ300億行（合計サイズ4TB）の3つの巨大なテーブル（構造化データ）があり、多数の同時ユーザー（リモートLANマシンの並列osスレッド）が一部を読み取る必要があることを想像してくださいSELELCT WHERE GROUPBYクエリと非常に同時、たとえば10,000同時読み取りによるデータと、ユーザーがこれらのテーブルにデータを挿入する必要があります（更新なし）2000同時書き込み（データセンターLANネットワーク全体） 。ユーザーは、このストレージから可能な限り高速で読み取りと挿入を行い、各読み取りと書き込みが行われる場所はms〜1秒の範囲です。 そのような要件を満たすために、どのテクノロジーをお勧めしますか？これを実行できるデータストレージまたはキーバリューストアはありますか？クラウドはオプションではありません。 いくつかの明確化： ユーザーはデータをすぐに見る必要はなく、最終的な一貫性は許容されます。データはストレージが提供できるドライバーを介してアクセスされ、ユーザーは再びデータセンターのリモートマシンで実行される単なるスレッドになります。クエリは、主にSELECT WHERE GROUPBYに似ています。 データは表形式で、各行は約60バイトです。 DynamoDBまたは同様のソリューションを使用できないクラウドオプションはありません。データセンターで内部的にホストできる必要があります。 テーブルのすべてのデータを常に読み取ることができ、使用パターンは予測できません。結合または超長いクエリはありません。DRは必要ありませんが、合理的なHAは必要ですが、空想である必要はありません。すべての読者は、where句に基づいて行のバッチを取得しており、行は実際には関連していません。各行の長さを固定することもできますが、ストレージレイヤーが心配することを期待しています。 また、私の最大の懸念は、同時読み取りで発生するすべての同時書き込みです。 これに対するあなたの洞察は非常に高く評価されています。 さらに、これらのテーブルのうち3つにそれぞれ300億行の異なるオブジェクトタイプがあります

12 architecture  concurrency  nosql  storage 

ストレージとパフォーマンスの両方の観点から、varchar列の大きさを決定する最良の方法を理解しようとしています。 パフォーマンス 私の研究から、それはそうですvarchar（max）は、本当に必要な場合にのみ使用してください。つまり、列が8000文字以上を収容する必要がある場合、1つの理由はインデックス作成の欠如です（ただし、一般にvarcharフィールドでのインデックス作成には少し疑いがあります。ただし、DBの原則はかなり新しいので、それが根拠がないかもしれません。 ）および圧縮（より多くのストレージの問題）。実際、クエリは可能な最大サイズを考慮しなければならないため、一般的に人々はvarchar（n）.... oversizingを行うときに必要なものだけを使用することを推奨しているようです。しかし、エンジンはデータの実際の平均サイズの推定値として、示されたサイズの半分を使用することも述べられています。これは、データから平均サイズを決定し、それを2倍にし、それをnとして使用する必要があることを意味します。ただし、変動性が非常に低いがゼロではないデータの場合、これは、最大サイズの最大2倍のサイズ変更を意味します。洞察をいただければ幸いです。 ストレージ 実際のストレージは実際のデータに制限されていることを念頭に置いて、行内ストレージと行外ストレージのしくみについて読んだ後、nの選択はストレージにほとんどまたはまったく影響がないように思えます（それがすべてを保持するのに十分な大きさであることを確認してください）。varchar（max）を使用しても、ストレージに影響はありません。代わりに、可能であれば、各データ行の実際のサイズを〜8000バイトに制限することが目標になる場合があります。それは物事を正確に読んでいますか？ コンテキスト 一部の顧客データは少し変動するため、通常、必要な列よりも少し幅を広く（たとえば15〜20％大きく）します。他に特別な考慮事項があるかどうか疑問に思っていました。たとえば、一緒に仕事をしている人から、2 ^ n-1サイズを使用するように言われました（ただし、それを証明するものは見つかりませんでした。 最初のテーブル作成について話している。新しいテーブルの送信を開始し、サンプルデータ（または最初の本番データセットのみ）を送信することをお客様から言われます。これを見て、データを保持するためのテーブルを作成します。将来のインポートとサンプルの内容を処理できるように、テーブルを作成します。ただし、特定の行は長くなるようにバインドされているため、それらをパディングします。 問題はどれくらいか、そして技術的なガイドラインはありますか？

12 sql-server  performance  best-practices  storage  varchar 

私たちは多くのLinux VMをvmware /共有ストレージ環境で実行しており、それぞれが独自のpostgreSQLインスタンス（9.0と9.3の混合）を実行しています。現在、VM全体が単一のルートパーティション/ボリューム上にあり、基盤となるVMFSボリュームのストレージベースのスナップショットをバックアップ/復元プロセス（および私たちのDRサイトへのレプリケーション）に使用することで大きな成功を収めています（約8年）。 ストレージのアーキテクチャーにより、postgres WALファイルをキャッシュされていない、大部分が書き込みボリュームに分離して、ストレージ側でのキャッシュチャーンを少なくすることが有利です。ストレージ（Nimble Storage）を使用すると、両方のボリュームを単一の保護/スナップショットグループに割り当てることができますが、スナップショットが保護グループ内のすべてのボリュームでまったく同時に発生することをベンダーから引き出すことができませんでした-可能性は高いですが、ミリ秒単位で離れている可能性は常にあります。 そのために、pg_benchを使用して可能な限り高速にデータをDBに書き込みながら、いくつかの実験を行いました。実験後、スナップショットのボリュームを復元し、VM + postgresを起動しました データボリュームとログボリュームの両方をほぼ同時にスナップショット作成-結果：DBが回復 最初にスナップショットデータボリューム、〜1分後にログボリューム-結果：DBが回復しました 最初にスナップショットログボリューム、約1分後にデータボリューム-結果：DBが回復しました WALチェックポイントがデータファイルに新しいデータを書き込んだ後、最初にスナップショットログボリューム、約3分後にデータボリューム：結果：DBが回復しました したがって、両方のスナップショットがボリュームレベルで一貫しており、比較的近い距離にある限り、WAL /ログボリュームのスナップショットの時間に基づいて、DBの一貫したコピーが得られます。 私の質問：これは安全ですか？テストで欠落している主なケースは何ですか？また、何が問題になる可能性がありますか？ Postgresのドキュメントはこれが安全ではないことを示していますが、テストはかなり堅牢であることを示しているようです：http : //www.postgresql.org/docs/9.1/static/backup-file.html データベースが複数のファイルシステムに分散している場合、すべてのボリュームの正確に同時に凍結されたスナップショットを取得する方法がない場合があります。たとえば、データファイルとWALログが異なるディスク上にある場合、またはテーブルスペースが異なるファイルシステム上にある場合、スナップショットは同時でなければならないため、スナップショットバックアップを使用できない場合があります。このような状況でコンシステントスナップショット手法を信頼する前に、ファイルシステムのドキュメントをよく読んでください。 注：はい、PostgreSQLをホットバックアップモードにしたり、ストレージのVMware統合を使用してVM自体を静止したりするなど、一貫性を確保する他のオプションについては知っていますが、スピードと利便性のためにストレージのみのソリューションを探しています。クライアントへの影響はゼロです。

11 postgresql  storage  virtualisation 

古いオールフラッシュアレイから新しいオールフラッシュアレイ（異なるが、確立されたベンダー）に移行すると、チェックポイント中にSQL Sentryで待機が増えることがわかりました。 バージョン：SQL Server 2012 Sp4 私たちの古いストレージでは、待機時間はチェックポイント中の「スパイク」が2,500で約2kでしたが、新しいストレージではスパイクは通常10kで、ピークは50k近くです。歩哨は私たちをPAGEIOLATCHワティスにもっと向けます。独自の分析を行うと、PAGEIOLATCH and PAGELATCH待機の組み合わせのようです。Perfmonを使用すると、一般に、チェックポイントを行うページが増えるほど、待機時間が長くなりますが、フラッシュするのは、チェックポイント中に〜125 MBだけです。私たちのワークロードはほとんどが書き込みです（主に挿入/更新）。 ストレージベンダーは、ファイバーチャネル直接接続アレイがこれらのチェックポイントイベント中に1 ms未満応答していることを証明しています。HBAはアレイの番号も確認します。また、キューの深さが8を超えることはなかったため、HBAキューの問題であるとは考えていません。また、ZIO、実行スロットル、およびキューの深さの設定を無効にして、新しいHBAを試しました。また、サーバーのメモリを500 GBから1 TBに変更せずに増やしました。チェックポイントプロセス中に、2〜4個のコア（16個のうち）が100％に急上昇しますが、全体的なCPUは約20％です。BIOSも高パフォーマンスに設定されています。興味深いことに、CPUがC2スリープ状態になっているのは無効にしたにもかかわらず、通常はC2スリープ状態であるため、スリープ状態がC1を超えた理由を調査しています。 ほとんどすべての待機が、DCMページタイプのPFSが時々発生するデータページで発生していることがわかります。待機はtempdbではなくユーザーDBで行われます。また、待機が複数のデータページにわたって行われ、一部のSPIDが同じページで待機していることもわかります。データベースの設計には、いくつかの挿入ホットスポットがありますが、同じ設計が古いストレージに配置されていました。 このクエリのループを100回実行すると、ディスクとメモリで待機しているSPIDの数を把握できました。 SELECT [owt].[wait_type], count(*) as waitcount FROM sys.dm_os_waiting_tasks [owt] WHERE [owt].[wait_type] LIKE 'PAGE%' group by [owt].[wait_type] order by 1 GO 100 「良い」ことは、同じモデル配列と類似のサーバー仕様を持つパフォーマンス環境で問題を簡単に再現できることです。他にどこを見るべきか、どのように問題を絞り込むかについての考えをいただければ幸いです。現在、次のテストは次のとおりです。新しいマザーボードとより多くのCPUを搭載した新しいサーバー。SIOSデータキーパーを無効にする（これが古いストレージで行われている場合でも）。異なるHBAブランド。 exec sp_Blitz @outputtype = 'markdown' 優先度5：信頼性：-危険なサードパーティモジュール-Sophos Limited-ソフォスのバッファーオーバーラン保護-SOPHOS〜2.DLL-危険と思われるサードパーティモジュールがインストールされています。 優先度200：情報：-クラスターノード-これはクラスター内のノードです。-TraceFlag On-トレースフラグ1117がグローバルに有効になります。-トレースフラグ1118がグローバルに有効になります。-トレースフラグ3226がグローバルに有効になります。 優先度200：ライセンス：-使用中のEnterprise Edition機能* xxxxx-[xxxxxx]データベースは圧縮を使用しています。このデータベースをStandard Editionサーバーに復元すると、2016 …

9 sql-server  sql-server-2012  storage  waits  checkpoint 

これはおそらく非常に自由な質問であり、答えはさまざまである可​​能性がありますが、SSDについて話すときのSQL Server 2012のtempdb、mdf、およびldfファイルの最適な配置は何ですか？ 新規購入前は、SQL Server 2012コアファイルとtempdbがインストールされた既存のSSDがあり、7200rpm HDDにmdf / ldfの両方がありました。次に、MDFとLDFを一方に配置するという当初の目的で、2つのSSDを購入しました。 しかし、それをさらに読み取ることから、SSDに関しては、mdfファイルとldfファイル用の個別の物理ディスクは実際には適用されません。正しい？ だから、私は次のことを考えていました： SSD 1-SQL Server 2012コアファイルおよびWindows SSD 2-tempdb SSD 3-mdfおよびldf それが違いを生む場合、これは1つのデータベースのみに割り当てられるため、複数のデータベース間で競合は発生しません。 私の "考えている"セットアップは良いですか、それとも単に無駄になっていますか（つまり、tempdbを分離する理由はありません）。

9 sql-server  sql-server-2012  storage 

約5m行の汎用ログテーブルがあります。 イベントタイプを格納する「厳密に型指定された」フィールドと、イベントに関連するデータを含む一連の「緩やかに型指定された」列があります。つまり、これらの「緩やかに型付けされた」列の意味は、イベントの型によって異なります。 これらの列は次のように定義されます。 USER_CHAR1 nvarchar(150) null, USER_CHAR2 nvarchar(150) null, USER_CHAR3 nvarchar(150) null, USER_CHAR4 nvarchar(150) null, USER_CHAR5 nvarchar(150) null, USER_INTEGER1 int null, USER_INTEGER2 int null, USER_INTEGER3 int null, USER_INTEGER4 int null, USER_INTEGER5 int null, USER_FLAG1 bit null, USER_FLAG2 bit null, USER_FLAG3 bit null, USER_FLAG4 bit null, USER_FLAG5 bit null, USER_FLOAT1 float …

9 sql-server  sql-server-2008  null  storage  sparse-column 

私はよく人が話して"char"いるのを見ます。使ったことがない。それはドキュメントで次のように定義されています： タイプ「char」（引用符に注意）は、1バイトのストレージのみを使用するという点でchar（1）とは異なります。これは、単純な列挙型としてシステムカタログで内部的に使用されます。 そしてさらに、 "char" 1 byte single-byte internal type それで、それが1バイトである場合、ドメインは何であり、どのようにそれを利用しますか？署名されていますか、署名されていませんか？@Erwin Brandstetterによるこの投稿では、彼はそれをレイアウトしていますが、私はまだ混乱しています。彼はand を使用してascii()おりchr()、これを提供しています SELECT i , chr(i)::"char" AS i_encoded , ascii(chr(i)::"char") AS i_decoded FROM generate_series(1,256) i; それは10から11の間で本当に奇妙なことをしています。 i | i_encoded | i_decoded -----+-----------+----------- ... 8 | \x08 | 8 9 | | 9 10 | +| 10 | | -- WTF …

9 postgresql  datatypes  storage  cast 

オラクルの公式ドキュメントでこの声明に出くわしました。 Microsoft SQL Serverでは、可変長データ型の列のみがNULL値を格納できます。固定長データ型でNULLを許可する列を作成すると、列は自動的にシステムの可変長データ型に変換されます... SQL Serverのドキュメントでこれについて読んだことも、そのようなことを経験したこともありません。逆に、SQL Serverでは、固定長のデータ型（intやfloatなど、charも）が頻繁に使用され、NULL可能でも非常に効率的に格納されます。 このオラクル声明の背後にある理論的根拠はありますか？！

8 sql-server  oracle  null  storage