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

現在、SQL Server開発スタッフ用のTEST環境を作成しています。 本番環境には3つのSQL Serverがあり、SQL01にミラーリングされたいくつかのデータベースが含まれていますSQL02。 SQL03「自動フェイルオーバーによる高い安全性」または同期構成での証人として機能します。 VMWare P2Vを使用して、3台すべてのマシンを個別のハードウェアに仮想化し、マシンのSIDを再構成し、これらの新しいマシンから本番サーバーのIPアドレスをブラックホール化しました。 最初はプロダクション監視マシンをブラックホール化するのを忘れていたので、TESTマシン上のデータベースはまだマシンを監視SQL03として使用していました。この問題に気付いて、私はTESTのデータベースを再構成して、新しく仮想化されたTESTの目撃者を指すようにしましたTEST03。 新しいミラーリング監視を使用するようにデータベースを再構成するには、プライマリサーバーで次のコマンドを入力しましたTEST01。 ALTER DATABASE [TestDB] SET WITNESS = 'TCP://TEST03.domain.inet:5022'; 予期しない応答がありました： The ALTER DATABASE command could not be sent to the remote server instance 'TCP://TEST03.domain.inet:5022'. The database mirroring configuration was not changed. Verify that the server is connected, and try again. 構成は運用マシンで機能し、テストマシンではまったく変更されていないため、このエラーメッセージに非常に困惑しました。 これを機能させるためLOGINに、テストの目撃者を作成する必要がありました。 CREATE …

10 sql-server  sql-server-2005  mirroring 

実際に削除を実行せずに、DELETEが制約違反に遭遇するかどうかを予測できるようにしたいと思います。 これを行うための私のオプションは何ですか？DELETEの「ドライラン」を実行する簡単な方法はありますか？

10 sql-server  sql-server-2008  sql-server-2005 

データベースのスカラー関数を更新したい。この関数は、キーテーブルのいくつかの計算列に使用されるため、更新しようとすると依存関係エラーが発生します。列を明示的に削除し、関数を更新して列を再度追加できますが、余計な手間をかけずに列の順序が変更され、他の意図しない結果が生じる可能性があります。もっときれいな方法はあるのだろうか？

10 sql-server-2008  sql-server-2005  functions 

クエリで指定された一意の識別子のうち、テーブルに存在しない一意の識別子を簡単に確認できるようにしたいと思います。 よりよく説明するために、リスト「1、2、3、4」のどのIDがテーブルに存在しないかを確認するために、私が今行うことは次のとおりです。 SELECT * FROM dbo."TABLE" WHERE "ID" IN ('1','2','3','4')、テーブルにID 2の行が含まれていないとしましょう。 結果をExcelにダンプする 結果リストの各リスト値を検索する元のリストでVLOOKUPを実行します。 結果となるVLOOKUP #N/Aは、テーブルで発生しなかった値になります。 これを行うにはもっと良い方法があるはずだと思います。私は理想的には次のようなものを探しています チェックするリスト->チェックするテーブルにクエリ->テーブルにないリストのメンバー

10 sql-server  sql-server-2005  except 

VARBINARYデータ長が2000までの場合、sys.fn_varbintohexstrは正常に動作します。それが2000より大きい場合、関数sys.fn_varbintohexstrは結果としてNULLを返します。何が欠けていますか？ DECLARE @testvarbinary VARBINARY(MAX) SELECT @testvarbinary = 0xFFD8FFE000104A46494600010100000100010000FFDB004300090607080706090807080A0A090B0D160F0D0C0C0D1B14151016201D2222201D1F1F2428342C242631271F1F2D3D2D3135373A3A3A232B3F443F384334393A37FFDB0043010A0A0A0D0C0D1A0F0F1A37251F253737373737373737373737373737373737373737373737373737373737373737373737373737373737373737373737373737FFC0001108007E005C03012200021101031101FFC4001B00000301010101010000000000000000000405060302010007FFC4003A100002010302030407080103050000000001020300041105211231411322516106718191A1B1D11423324252C1E1F03315247243A2D2E2F1FFC4001801000301010000000000000000000000000102030004FFC4001F1100020202020301000000000000000000000102112131034104122251FFDA000C03010002110311003F0096D26DAD2EB4BBBC1646E364000186380727C39FC2A05B218827383E35AC17B728922C7348A24FC60311C5EBACD237918051B9341D195A307C96C64D36D27499EE5FF0777AB31D97D746E97A4A16E39003C232CCC365AABD3AC85C42643C50D9A1FC58EF48454E53E91451B02B2D3ECED8810C4D7328DCB636ACF51BD78BBA63B751FA55B71EEA677921951A2B45FB3DA2F7709F89CF866A7353B66B6004B1852DBAC406E079D4AECA7AD0BEF6E44B8DB881DB0798F6D130D8D9DC420714EAF8DF707E9418B476513721C54C6C1256DE37E3239A9FA1D8D35D681562CBCD1A54FF0019627A6DBE3D54B5A09A26C12411E35FA1C68AD082008F6EF2F41E04797974A5BA9E991CE1C6386451B8E7ED1E345727E81C3B44A6188C926B48D805DCD75240CAC4374D8D0ECC1588C8F7D6AB1927583388851DEF7535D1ED8C8C5C292C7650694440C9270AEFBE6ACF4B8858E9C6E1C0E23B463CFC69E6E9118AB633D3AC3ED320B356C229E295C7C7E9EDA6F74DDB4B1D9DB2948D06000390AE74E84E9FA2F6B201DBCC3888EBBF214D74DB0105AB4B311DAB6ECC7E35CECE840B1DB2C518729961DD894F8D21BBD225BEBB62F9E007BCDD5CFD2AB228CDC66729C2A470C6BE0BFCD3286C91635D86E36DB993D6A6DB2918D91EBE8D3ADAA86C14639DFA5663D1E303A48991C2D8C8E87A57E866D87095C023C3C4560F64ACAF19C77971F434136525049123358B346268D543755C6C1BA8F51FDE95DCDB2B2F0AF351C51127703A827C460FBAAD161CA14FD6A41F261492F20026E3E1C296E21EDC1FEFAEA8883FC3F3DD52139ED00DCECC078D4DC9FE47C83CFC6AFB5CB2E195C22F5181ECC8F854BC964B2396006FCF90ABC1A233BD03E8B6FDADD2AE3CD8F80AB4B5B7FB76A76F6ABFE187BCD8F01CFE9483D1C80C61A4DB8B9EFF0001EFAAFD11560866BACE4B37086F21FD149C92B6371AA563591BB7BD8D3AF1777D7E34F6FA2ED3B2B31B2FE7C780E7F1DA907A384DDEA6D70C3B918E5E7FFC154AF8E29253D7BA0F90E7F1A9B781D2C9922069046ABDDD89F2F01FDF1A38292CB9F1A5F1DC3DAAF69716B2AAB9CF1819029B5ACB14F1C6F1B060C720D4D659D4B11356D872359B3F7D49D803BD17819C30A1E60983D3D7B51780ED500CF188AE4961D5587CA94EA30A8561D158EDE40E7E54E2ECF1C711CE79C648E9E1F3A5D749DBBA2EF97183EBE1A7E8E56B24BEA9171C6CC17246304788FEFC6A52EED1A3B9902120139D9B156F703B4B7CE7018FCC72A437363DBC9C5B02060ED4F1744E684DA70ECEC95B18E3CB7B05502B18748894ECDC238BD6DBFC89A5420FB94893C900A6BA903C10460EEC4B7B3181F0A57B19690EBD17FB8D34CA7F14CE5BD9FD1F1A375BBD92C6D2111A34B2960AA396FD727D64579A7C417B0B755FF181CBCBF9A6325A25DC87B400AA8C2F5A4BAD958C6DE09DB9D6B5A8EE96DD96D431E1EE8E271B8EA718F0F953CB2BB3C28C53B321B0E80EC0E456ADA45A63F0AE7C45613F6513A45100006DF029A4E2F48A45495DBB1D5EDE2A22F06E481B679D25D46FB4F8A45935092490A8FC11F1103D82B4BC950CF0E3903C8D793E97DB44F1A4AE9139058039CEF9FAD2C527B0BBAC1B417F61A8E9F33E9EEA5232090A4F74AF4DFD62BE231340413857CE7CBFA687D1B4DFB0B4D0AE7B29179F0E370303E1F2AD94F02A679E7869A5558219BC89EE515219106E63908DCF81A4174F2097EEC1E1C550DEA94B9BB5D8F112DFBD20C01CCD61582411333478EB9738E9B81464FF0079A84791DD5C03EFFE2B98814310DB90F6EDFCFC2BCE2FF7AF93B81CEB3322A74C7096F2DCB6C48DA8FB07E241BD4E25D715AA42A4E589DBCB63FC53BD31F85064E71492C1D3C237108E1E291B6E805235B888EA0BC6705F2513C05357B81FAB7C50C91DBBB481CA90472CF5A08A340DAB5C5BFDB638EDD959970C573838EB4E218CAC48C84B46C32A7C296358C0854C78CE3761CCFB69ADADC048C28C70A8C628E0D4CE269993209DFA1A5CEE385C83B238F767F9AD354982AB303D29569F722EDAE946E1635EBD467FF5A2B289F2A4A99C5F3715E7AD37F76FF2A9B983472B29C839A757127FBD018EE57F73F5A597E02DC927F300DCBDFF001CD325673CB07CD91328076046287656ED1F6C96C8DBD75B4985556272437BB72298DA409D8971F9188FDEB4B6088B349B9692FE78A418ECC285F31CC9F88AABB1DDCA13B11B5405F3CB6DE91433440FDE479651F98787C2ABF4EBF8EE22574700FCAB4E25B8A411AB5BDD9938ADA72D1E30571B8A1218AE480639FB391464E485F9D39B56ED46 select datalength(@testvarbinary) SELECT sys.fn_varbintohexstr(@testvarbinary)

10 sql-server  sql-server-2005 

私はどういうわけかそれを動作させるように近いと思いますが、何らかの理由でまだエラーが発生します。 次のUPDATEクエリがあります。 UPDATE DeviceAttribute SET Details = CASE Name WHEN 'Accessories' THEN @Accessories WHEN 'Description' THEN @Description WHEN 'Specification' THEN @Specification ELSE Details END WHERE DeviceID = 10 パラメータは、さまざまなユーザーによって入力されます。私が今直面している問題は、単一のフィールドを更新したい場合でも、他のパラメーターを古いデータで埋めなければならないということです。したがって、私はオプションIF @parameter IS NULL THENを設定し、すでにDBに格納されている値を保持したいと考えています。私はいくつかの解決策を見つけようとしましたが、次のクエリのようなものが解決策のようですが、それを機能させることができません： UPDATE DeviceAttribute SET Details = CASE Name WHEN 'Accessories' IS NOT NULL THEN @Accessories WHEN 'Description' IS …

10 sql-server  sql-server-2008  sql-server-2005 

SQL Serverの管理は初めてですが、SQL言語とSSISパッケージの作成に慣れています。 SQL Server 2005から2016にデータを移行したい。 私の質問は、システムデータベースや、インデックス、ストアドプロシージャ、ビュー、セキュリティ、権限などの他のオブジェクトについて心配する必要があるかどうかです。ログインまたは単にデータを移行できますか。 この場合、どちらをお勧めしますか。

9 sql-server  sql-server-2005  migration  sql-server-2016 

SQL Server 2005を使用しています。集計情報を含む2つのテーブルがあります。情報は常に更新されており、1日にほぼ5GBのログデータが生成されます。（データベース全体よりも大きい！）ロールバックは本当に必要ないので、これらのテーブルのロギングを無効にしたいと思います。ただし、データベース内の他のテーブルにログオンし続けたいと思います。 データベース内の特定のテーブルのロギングを無効にすることは可能ですか？そうでない場合、2つのテーブルを同じスキーマに配置して、スキーマへのロギングを無効にできますか？2つのテーブルを別のデータベースに移動し、そこでログを無効にする唯一のオプションはありますか？ 更新： これらのテーブルのアクティビティをログに記録する必要がない理由を説明します。 2つのテーブルにはGPSデータが含まれているため、かなり大きくなります。最初のテーブルは、フィールド内の6つのAndroidテーブルから生の場所をキャプチャしています。各タブレットからの新しいデータは5〜10秒ごとに送信されます。その情報は、locationA、locationB、travelTimeとして集約されます。最終的には、実際の運転データに基づいて、すべての場所間の移動時間を最短にすることが目標です。データは小都市のみのものであり、小数点第4位までしか正確ではないため、管理可能です。ただし、新しい生データが入力されると、更新が必要な移動時間が遅くなり、新しい移動データが挿入される必要があります。 生データが集約されると、パージされます。長い移動時間に戻ることはないので、これらのテーブルではロールバックはそれほど重要ではありません。

9 sql-server  sql-server-2005  transaction-log 

毎月、本番データベースの月末のスナップショットを作成しています。これらの月末のスナップショットは、レポート作成のみを目的としており、挿入、更新、削除は行われていません。これらの各スナップショットには、.MDFand .LDFファイルがあります。 .LDFファイルを削除してサーバーの空き容量を増やしたい。.LDFファイルを保持する必要がある理由はありますか？ 明確化： 本番データベースは、別のシステムからのファイル抽出から毎晩再作成されます。本番データベースからのレポートのみです...更新は行われません。 毎晩のプロセス： 私が言えることから... 毎晩、データベーステーブルは切り捨てられ ますテーブルは、一連の一括挿入ステートメントを介して入力 されますインデックスは再構築されます

9 sql-server  sql-server-2005  backup  datafile 

日付と時刻を別々の列に保持するというソフトウェアベンダーの決定を理解しようとしています。たとえば、行が作成または更新されたとき。時間と日付はどちらもDateTime列です。SQL Server 2005を使用しています。 データベースにはERPシステムのデータが保持されており、最大のテーブルには約300万行が含まれていると思います。ほとんどのテーブルは、おおよそ100 000〜1 000 000行です。 私は個人的にはデフォルトで、単一のタイムスタンプに対して単一のDateTimeを選択します。これにより、時間差の計算が容易になり、日付と時刻の部分をタイムスタンプから簡単に抽出できます。また、使用するスペースも少なくなります。 日付と時刻を分離することは悪い習慣なのでしょうか、それともこのデザインに理解できない非常に素晴らしいものがあるのでしょうか？

9 sql-server-2005  database-design 

デッドロックのシナリオに遭遇しています。デッドロックの唯一の関係者は、単一のテーブルと、そのテーブルから削除する単一のストアドプロシージャであるように見えます。エラーログのトレースを解読するガイドラインとして以下のMSDNの記事を使用して、これらのデッドロックのいくつかの時点でのSQLエラーログの私の分析に基づいて、その結論を導き出しました。 テーブルDEXTableとストアドプロシージャClearDEXTableRowsを以下に定義します。DEXTableに行を挿入する別のストアドプロシージャInsertDEXTableRowがありますが、そのプロシージャはSQLエラーログのエントリに基づくデッドロックに関与していないようです。 DEXTableには約830万行があり、着実に成長する傾向があります。回答者のテーブルも大きく、着実に成長する傾向があります。 ClearDEXTableRowsとInsertDEXTableRowをすばやく連続して頻繁に呼び出すページがある、トラフィック量の多いWebサイトからアクセスされます。 デッドロックは、過去10日間、1日あたり0〜9回発生しました。 1222のSQLトレースを有効にし（DBCC TRACEON 1222を使用）、最近フラグ1204を有効にしました。デッドロックの検出と終了に関するこれらのフラグの出力については、適切な説明があります 私の質問は： この1つのストアドプロシージャClearDEXTableRowsだけがデッドロックの原因であることは理にかなっていますか？ もしそうなら、誰もがこれがどのように起こり得るかの良い説明を提供し、それを修正する方法を勧めることができますか？ 私の疑いは、DELETEステートメントが頻繁に再構築する必要があるDEXTableのPKで競合を引き起こしていることです。 そうでない場合、デッドロックの原因をさらに掘り下げるには、どのような追加のトレースを有効にする必要がありますか？（私はここで学びたいです） -- Table definition CREATE TABLE [dbo].[DEXTable]( [ExportID] [int] NOT NULL, [RespondentID] [int] NOT NULL, [Exported] [datetime] NOT NULL, CONSTRAINT [PK_DEXTable] PRIMARY KEY CLUSTERED ( [ExportID] ASC, [RespondentID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = …

9 sql-server-2005  primary-key  deadlock  logs  upsert 

内部で使用するためのキー列がありますが、これは増加する整数ですが、UUIDである2番目の一意の列が欲しいのですが、デフォルト値を呼び出す関数を持つ方法がわかりません（SQLサーバーはJavaではなくUUIDを作成しています）、これについて私に提案できるドキュメントはありますか？

9 sql-server  sql-server-2005 

私のオフィスには、見苦しいクエリがありますが、運用環境と開発環境（それぞれ20秒と4秒）でかなりうまく実行されます。ただし、テスト環境では4時間以上かかります。SQL2005（+最新のパッチ）は、本番環境および開発環境で実行されています。SQL2008R2はテストで実行されています。 クエリプランを確認したところ、SQL2008R2はリンクサーバーから返された行を格納するために、テーブルスプール（レイジースプール）を介してTempDBを使用していることがわかります。次のステップは、クエリの96.3％を消費しているネストされたループ（左反準結合）を示しています。2つのオペレーター間の境界線は5,398MBです。 SQL 2005のクエリプランでは、tempdbの使用とLeft Anti Semi Joinの使用は示されていません。 以下はサニタイズされたコードであり、実行計画は2005年の計画を上に、2008R2は下を計画しています。 劇的なスローダウンと変化の原因は何ですか？別の実行プランが表示されることを期待していたので、気になりません。クエリ時間の劇的なスローダウンが私を悩ませています。 2008R2バージョンはtempdbを使用しているため、基盤となるハードウェアを確認する必要がありますか？その使用を最適化する方法を確認する必要がありますか？ クエリを記述するより良い方法はありますか？ 助けてくれてありがとう。 INSERT INTO Table1_GroupLock (iGroupID, dLockedDate) SELECT Table1.iGroupID, GETDATE() FROM Table1 WHERE NOT EXISTS ( SELECT 1 FROM LinkedServer.Database.Table2 Alias2 WHERE ( Alias2.FirstName + Alias2.LastName = dbo.fnRemoveNonLetter(Table1.FullName) AND NOT dbo.fnRemoveNonLetter(Table1.FullName) IS NULL AND NOT Alias2.FirstName IS NULL AND NOT …

9 sql-server-2008  sql-server-2005 

過去数か月間、TempDB DDL競合の問題が発生しているSQL Server 2005 Standard x64があります。サーバーは待機リソース2：1：103（待機タイプはPAGELATCH_EX）で競合が発生します。 この問題は、サーバーに適切な負荷がかかっているときに散発的に発生するようです。私は「破壊用の一時テーブル」のレートを監視しており、2：1：103でPAGELATCH_EXの問題が発生しているときに5,000以上にジャンプする可能性があります。私が読んだことから、このカウンターはほとんどの場合0であるはずですが、私たちのカウンターはほとんどの場合300〜1100のどこかにとどまっているようです。システム上のユーザーが非常に少ない場合にのみ、カウンターは0になります。 干し草のスタックで針を探す必要なしに、tempdbのDDL競合の原因を絞り込むにはどうすればよいですか？

9 sql-server  performance  sql-server-2005  ddl  tempdb 

SQLサーバーに関する別の質問：カウンターがリセットされて以来、最もCPUを集中的に使用するSQLを提供する簡単なクエリがあります。 select top 10 sum(qs.total_worker_time) as total_cpu_time, sum(qs.execution_count) as total_execution_count, qs.plan_handle, st.text from sys.dm_exec_query_stats qs cross apply sys.dm_exec_sql_text(qs.plan_handle) as st group by qs.plan_handle, st.text order by sum(qs.total_worker_time) desc 質問1：正確には何plan_handleですか？Oracleのように、計画のハッシュではないように見えます。発言の計画に変化があった状況を発見したいのでお願いします。 質問2：plan_handleを取得したら、実際の計画に興味があります。だから私は、例えば： select * from sys.dm_exec_query_plan (0x060006001F176406B8413043000000000000000000000000) query_plan列には、クリックするとXMLドキュメントを表示するリンクが表示されます。それをwhatever.sqlplanとしてディスクに保存すると、Windowsでそれをダブルクリックでき、Management Studioで正しく表示されます。きっとこのステップを回避する方法があるに違いない！？ 質問3：SET SHOWPLAN_TEXTの昔のように、XMLをテキスト形式に戻す方法はありますか？グラフィカルに表示できるようにしたいが、意味のある方法で差分を自動化したい。 ありがとう！

9 sql-server-2005  performance