タグ付けされた質問 「enterprise-edition」

3
varchar(255)またはvarchar(256)?
テーブルを使用する必要がありますvarchar(255)かvarchar(256)?列の長さ、またはメタデータの保存に1バイトが使用されていると聞きました。 この時点でそれはもう重要ですか? 私はインターネット上でいくつかの投稿を見ましたが、それらはOracleとMySQLに適用されます。 Microsoft SQL Server 2016 Enterprise Editionがありますが、この環境にどのように適用されますか? ここで、たとえば、テキストの説明を256ではなく255文字に保つようにクライアントに指示した場合、違いはありますか?私が読んだこと「DBMSは255文字の最大長で、フィールド内のデータの長さを示すために単一バイトを使用することを選択できます。制限が256以上の場合、2バイトが必要になります。」これは本当ですか?

3
DBテーブルでのSPIDの使用(テーブル変数の代わり)
予約に使用されるトランザクションデータベース... 私たちのベンダーは、#temptablesを@tablevariablesに置き換えるように依頼されました(コンパイルロックが重いため)。代わりに、SPIDを列として追加する実際のテーブルに置き換えて、ストアドプロシージャが適切な行でのみ機能するようにしました。 この操作方法にリスクはありますか?すべてのトランザクションが独自のトランザクション内に分離される前に...このテーブルを大量にロックしてしまうのではないかと心配しましたが、SQLは行レベルのロックを使用しているため、これ以上のロックは作成されないというのが彼らの意見です。 SQL Serverバージョン:2016 Enterprise-13.0.5216.0 CREATE TABLE dbo.qryTransactions ( ID int IDENTITY (0,1) NOT NULL CONSTRAINT pk_qryTransactions PRIMARY KEY CLUSTERED, spid int NOT NULL, OrderID int, ItemID int, TimeTransactionStart datetime, TimeTransactionEnd datetime, ...other fields ) CREATE INDEX idx_qryTransactions_spidID ON qryTransactions (spid, ID) INCLUDE (ItemID, OrderID, TimeTransactionStart, TimeTransactionEnd)

2
SQL Server 2016 Enterpriseのパフォーマンスが低い
長くなって申し訳ありませんが、分析に役立つように、できるだけ多くの情報を提供したいと思います。 同様の問題のある投稿がいくつかあることは知っていますが、これらのさまざまな投稿やWebで入手可能なその他の情報を既にフォローしていますが、問題は解決しません。 SQL Serverのパフォーマンスに深刻な問題があり、ユーザーを狂わせています。この問題は数年間続き、2016年末までは別のエンティティによって管理され、2017年以降は私が管理するようになりました。 2017年の半ばに、Microsoft SQL Server 2012パフォーマンスダッシュボードレポートに示されているインデックス付けのヒントに従って問題を解決することができました。効果はすぐに現れ、魔法のように聞こえました。最後の数日はほとんど常に100%だったプロセッサーが非常に穏やかになり、ユーザーのフィードバックが鳴り響きました。通常、特定のリストを取得するのに20分かかり、最終的に数秒で完了できるため、ERP技術者でさえ喜んでいました。 しかし、時間の経過とともに、それは徐々に悪化し始めました。インデックスが多すぎるとパフォーマンスが低下するのではないかと心配して、インデックスの作成を避けました。しかし、ある時点で、不要なものを削除して、Performance Dashboardが提案する新しいものを作成する必要がありました。しかし、影響はありません。 ERPでの保存とコンサルティングの際に感じられる遅さは本質的にです。 次の構成のSQL Server 2016 Enterprise(64ビット)専用のWindows Server 2012 R2があります。 CPU:Intel Xeon CPU E5-2650 v3 @ 2.30GHz メモリ:84 GB ストレージに関して、サーバーにはオペレーティングシステム専用のボリューム、データ専用のログ、およびログ専用のボリュームがあります。 17データベース ユーザー: 最大のDBでは、ほぼ113人のユーザーが同時に接続されています 他には約9人のユーザーがいます それらの2つで3 + 3 残りのユーザーはそれぞれ1人だけです 大規模なデータベース用にも作成するWebがありますが、使用頻度ははるかに低く、約20人のユーザーがいるはずです。 DBのサイズ: 最大のデータベースは290 GBです。 2番目に大きいものは100 GB 3番目に大きいものは20 GB 4番目の14 GB 残りはそれぞれ3 GBを少し超えています これは本番環境のインスタンスですが、ほとんどの場合私がそこに接続しているだけなので、この目的のために無視できると思われる開発のインスタンスもありますが、この問題は、接続していない場合でも常に発生します。 プロセッサはほとんどの場合、次のようになります。 …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.