タグ付けされた質問 「sql-server-2008-r2」

SQL Server 2008 R2（メジャービルドバージョン10.50.xxxx）。また、sql-serverでタグ付けしてください。

5
ALTER COLUMN to NOT NULLが大量のログファイルの増加を引き起こすのはなぜですか？
データ用にディスク上に4.3 GBを使用する64m行のテーブルがあります。 各行は約30バイトの整数列に加えて、NVARCHAR(255)テキスト用の可変列です。 data-typeのNULLABLE列を追加しましたDatetimeoffset(0)。 次に、すべての行でこの列を更新し、すべての新しい挿入でこの列に値が配置されるようにしました。 NULLエントリがなくなったら、このコマンドを実行して新しいフィールドを必須にしました。 ALTER TABLE tblCheckResult ALTER COLUMN [dtoDateTime] [datetimeoffset](0) NOT NULL その結果、トランザクションログサイズが大幅に増加しました。スペースがなくなるまで、6GBから36GBを超えました。 SQL Server 2008 R2がこの単純なコマンドでこのような大きな成長をもたらすために一体何をしているのか、誰にもわかりませんか？
4
2008 R2よりもSQL Server 2012を好む客観的なビジネス上の理由は何ですか？
私の会社は、新しいデータベースサーバー用にSQL Server 2012 DenaliとSQL Server 2008 R2のどちらを購入するかの決定に直面しています。客観的な理由を探して、どちらかを選択します。 私たちの要件： Standardエディション（経済的理由およびエンタープライズ機能の必要性の欠如のため） OLTPワークロード（つまり、新しいウィンドウ関数と列ストアインデックスは不要です） 10〜100 GBのデータベースサイズ ビジネスインテリジェンス機能は必要ありません。リレーショナルエンジンのみが必要です 同期データベースミラーリング 現在、次の理由がわかっています。 SQL Server 2012デナリ 利用可能な最新バージョン SQL Server 2008 R2 実績のある技術 どちらか一方を好むという技術的な理由はあまりないようです。基本的に、成功している実績のあるテクノロジーと、利用可能な最新かつ最高のバージョンを選択することになります。 決定を下す客観的な理由は何ですか？
2
互換性レベル80の実際の動作は何ですか？
互換モード機能に関するより良い洞察を誰かが提供してくれますか？予想とは異なる振る舞いをしています。 互換モードを理解している限り、SQL Serverのさまざまなバージョン間の特定の言語構造の可用性とサポートに関するものです。 データベースエンジンバージョンの内部動作には影響しません。以前のバージョンではまだ利用できなかった機能と構成の使用を防止しようとします。 SQL Server 2008 R2で互換レベル80の新しいデータベースを作成しました。単一のint列を持つテーブルを作成し、いくつかの行を追加しました。 次に、row_number()関数を使用してselectステートメントを実行しました。 私の考えでは、row_number関数は2005年にのみ導入されたため、compat 80モードではエラーがスローされます。 しかし、驚いたことに、これはうまくいきました。そして、確かに、コンパットルールは、「何かを保存」して初めて評価されます。そこで、row_numberステートメントのストアドプロシージャを作成しました。 ストアドプロシージャの作成は問題なく行われ、完全に実行して結果を得ることができました。 誰かが互換モードの動作をよりよく理解するのを手伝ってくれますか？私の理解には明らかに欠陥があります。
5
SQL Serverでのデータの難読化
SQL Serverでのデータ難読化のベストプラクティスは何ですか？ UATシステムでマスクされた生産データを使用したいと思います。 より迅速に、より高いレベルの難読化でそれを行いたい場合、どのようなアプローチをとるべきですか？人々の名と姓のスクランブルについて考えていますが、どうですか？自分で関数を作成する必要がありますか、それとも使用可能な定義済み関数がありますか？車輪の再発明に時間をかけたくありません:) 日付フィールドはどうですか？たとえば、生年月日をテーブル全体からランダムに選択してレコードに割り当てる必要がありますか、それとももっと良い方法がありますか？
1
DATETIME2を返すGETDATE（）の類似物はありますか
MSDNによると、Getdate（）、GetUtcDate（）、およびCURRENT_TIMESTAMPはすべてDATETIMEを返します。次のことを確認する短いテストを実行しました。 CREATE TABLE #t(T DATETIME2(7)); GO DECLARE @i INT ; SET @i=1; WHILE @i<10000 BEGIN ; INSERT #t VALUES(CURRENT_TIMESTAMP) ; SET @i=@i+1; END ; SELECT DISTINCT t FROM #t ORDER BY t ; --- 2013-01-28 13:23:19.4930000 2013-01-28 13:23:19.4970000 2013-01-28 13:23:19.5000000 2013-01-28 13:23:19.5030000 2013-01-28 13:23:19.5070000 2013-01-28 13:23:19.5100000 2013-01-28 13:23:19.5130000 （をちょきちょきと切る） DATETIME2（7）を返す同様の関数はありますか？
3
WHERE INを使用した削除操作中の予期しないスキャン
次のようなクエリがあります。 DELETE FROM tblFEStatsBrowsers WHERE BrowserID NOT IN ( SELECT DISTINCT BrowserID FROM tblFEStatsPaperHits WITH (NOLOCK) WHERE BrowserID IS NOT NULL ) tblFEStatsBrowsersには553行あります。 tblFEStatsPaperHitsには47.974.301行があります。 tblFEStatsBrowsers： CREATE TABLE [dbo].[tblFEStatsBrowsers]( [BrowserID] [smallint] IDENTITY(1,1) NOT NULL, [Browser] [varchar](50) NOT NULL, [Name] [varchar](40) NOT NULL, [Version] [varchar](10) NOT NULL, CONSTRAINT [PK_tblFEStatsBrowsers] PRIMARY KEY CLUSTERED …
6
トップ1を追加するとパフォーマンスが劇的に低下するのはなぜですか？
私はかなり単純なクエリを持っています SELECT TOP 1 dc.DOCUMENT_ID, dc.COPIES, dc.REQUESTOR, dc.D_ID, cj.FILE_NUMBER FROM DOCUMENT_QUEUE dc JOIN CORRESPONDENCE_JOURNAL cj ON dc.DOCUMENT_ID = cj.DOCUMENT_ID WHERE dc.QUEUE_DATE <= GETDATE() AND dc.PRINT_LOCATION = 2 ORDER BY cj.FILE_NUMBER それは私に恐ろしいパフォーマンスを与えています（それが終わるのを待つことを決して気にしないような）クエリプランは次のようになります。 しかし、削除するTOP 1と、次のような計画が得られ、1〜2秒で実行されます。 以下のPKとインデックスの修正。 TOP 1クエリプランが変更されたからといって驚くことはありませんが、それによって事態がさら​​に悪化していることに少し驚いています。 注：この投稿の結果を読んで、a Row Goalなどの概念を理解しています。私が興味を持っているのは、より良いプランを使用するようにクエリを変更する方法です。現在、データを一時テーブルにダンプしてから、最初の行を取り出しています。より良い方法があるかどうか疑問に思っています。 編集事実の後にこれを読んでいる人々のために、ここにいくつかの追加情報があります。 Document_Queue-PK / CIはD_IDであり、〜5k行があります。 Correspondence_Journal-PK / CIはFILE_NUMBER、CORRESPONDENCE_IDで、行数は約140万です。 私が始めたとき、他のインデックスはありませんでした。私はCorrespondence_Journal（Document_Id、File_Number）で1つになりました
3
UATサーバーとPRODサーバーの実行計画の違い
UAT（3秒で実行）とPROD（23秒で実行）で同じクエリを実行すると、なぜこんなに大きな違いがあるのか​​を理解したいと思います。 UATとPRODの両方に、正確なデータとインデックスがあります。 クエリ： set statistics io on; set statistics time on; SELECT CONF_NO, 'DE', 'Duplicate Email Address ''' + RTRIM(EMAIL_ADDRESS) + ''' in Maintenance', CONF_TARGET_NO FROM CONF_TARGET ct WHERE CONF_NO = 161 AND LEFT(INTERNET_USER_ID, 6) != 'ICONF-' AND ( ( REGISTRATION_TYPE = 'I' AND (SELECT COUNT(1) FROM PORTFOLIO WHERE EMAIL_ADDRESS …
3
実行計画の基本—ハッシュマッチの混乱
私は実行計画を学び始めており、ハッシュマッチが正確にどのように機能するのか、そして単純な結合でそれが使用される理由について混乱しています： select Posts.Title, Users.DisplayName From Posts JOIN Users on Posts.OwnerUserId = Users.Id OPTION (MAXDOP 1) 私が理解しているように、トップインデックススキャンの結果はハッシュ可能になり、ボトムインデックスクラスタースキャンの各行が検索されます。ハッシュテーブルが少なくともある程度機能することは理解していますが、このような例ではどの値が正確にハッシュされるかについて混乱しています。 私が理にかなっているのは、それらの間の共通フィールドであるidがハッシュされていることですが、もしそうなら、なぜ数値をハッシュするのでしょうか？
1
データベースの単純または完全復旧モデル？
いつ完全復旧モデルを使用する必要があり、いつデータベースの単純復旧モデルを使用すればよいですか？ デフォルトであるため、常に完全復旧モデルを使用しましたが、今日このエラーが発生しました： SQL Server用Microsoft OLE DBプロバイダー（0x80040E14）データベース 'DATABASE NAME'のトランザクションログがいっぱいです。ログ内のスペースを再利用できない理由を確認するには、sys.databasesのlog_reuse_wait_desc列を参照してください。 特定のデータベースは、実際にはサーバー上で最小かつ最も非アクティブなデータベースの1つであるため、他のデータベースではなく、このデータベースでログがいっぱいになる方法がわかりません。 ログを圧縮してデータベースに再度アクセスできるようにするには、次のコマンドを使用して、復旧モデルをFULLからSIMPLEに変更し、論理ファイルログを圧縮しました alter database myDbName SET recovery simple go dbcc shrinkfile('LOG FILE LOGICAL NAME', 100) go それは助けたが、今私が理解する必要がなぜ、それが助けHOWこの状況が開始され、どのように将来的にはこれを防ぐには？ 編集： 毎晩1時に、サーバー上のすべてのデータベースのスクリプト化されたバックアップを行っています。これは、31行のスクリプトで行われています。最も重要な部分は set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak' set @Description = 'Full backup of database …
5
SQL Serverがより多くのサーバーメモリを消費するのはなぜですか？
SQL ServerはサーバーRAMの87.5％を消費しています。これは最近、速度低下などの多くのパフォーマンスのボトルネックを引き起こしました。この問題を調査しました。インターネットで見つけることができる一般的な解決策の1つは、SQL Serverの最大制限を設定することです。これが行われ、多くの改善が得られました。最大メモリ値が設定されていない場合、SQL Serverがリソースを消費し続ける理由を知りたい
5
なぜvarcharデータ型がまだあるのですか？
私のデータベースの多くには、varcharとして定義されたフィールドがあります。私はアメリカに住んで働いているので、これはそれほど問題ではありませんでした（存在する唯一の言語は「アメリカ人」です。ahem） 約5年間データベースを操作した後、最終的にvarcharフィールドの性質が限られているという問題に遭遇し、nvarcharとしてデータを保存するためにフィールドを変更する必要があります。テーブルに別の更新を行い、varcharフィールドをnvarcharに変換しなければならなかった後、私は考えました-なぜこのようにまだ行うのですか？私はずっと前から、新しいテキストフィールドをすべてvarcharではなくnvarcharに定義するという精神的な決定をしました。これは、10年前に学校にいたときに教科書から学んだことです。 2011年で、昨年SQL Serverの新しいリリースがありました。代わりにnvarcharを使用できる/すべきであるのに、なぜvarcharデータ型をサポートし続けるのですか？ nvarcharsはvarcharsの「2倍」であるとよく言われることを知っているので、varcarを保持するための1つの論点として、ストレージスペースの使用が考えられます。 ただし、今日のユーザーは、ストレージスペースを節約したい場合、デフォルトのUTF-16ではなくUTF-8としてデータを保存するようにnvarcharを定義できます。これにより、主に望ましい場合は8ビットエンコーディングが可能になりますが、DBに挿入される2〜8バイトのまれな文字が何も破損しないことが保証されます。 何か不足していますか？過去15〜20年でこれが変わっていない理由はありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.