Microsoft SQL Server 総合スレ 11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Microsoft SQL Server (Transact-SQL) の総合スレッドです。 ・Microsoft 公式サイト http://www.microsoft.com/japan/sql/ 過去スレとかめんどいから誰か適当に貼って >>225 なんですかそれは? >>226 ああ、勘違いでした。 order byしてもしなくてもクエリ自体は一瞬で終わっていました。 時間が掛かるのは C#でDataTableにloadで読み出しているところでした。 1行が1KBくらいのデータ 200,000行なので、200MBくらいのデータを読み出している計算になりますか。 その場合、20秒くらい掛かるもんですか?1秒以内くらいにできますか? sql serverとsql server express は速さは違うのでしょうか? >>231 条件による 使えるメモリーとかコア数違うから updateするときに、違いがなかったらupdateされないようにしたいです。 (トリガーで履歴を取っているのと、timestamp列が無駄に変わるのを防ぎたいため) そこで、updateのwhereに binary_checksum(項目1,項目2,項目3,・・・)<>binary_checksum(@項目1,@項目2,@項目3,・・・) ってのを追加してます。 概ねいいんですが、かなり単純な条件でコンフリクトが発生しました。 bit型の項目1と項目9があって、項目1:1→0,項目9:0→1 のとき、binary_checksumが一緒になるという・・・ HashBytes だと () の中に複数の項目が書けません。 binary_checksumみたいな () に複数項目が書けるもので、もうちょっとコンフリクト起きにくいなにかないですか。 >>239 コンフリクトの使い方間違ってるんじゃないか? それはともかく、単純にwhere old_item1 <> new_item1 or old_item2 <> new_item2 or ... ってやるのは駄目なのか? binary_checksumがどうやって計算してるかしらんが、たとえば単純なsumだったら (1,0)と(0,1)が同じ値になるのは当然だわな 素直に全項目比較する方がいいんじゃね どういう状況かわからんが、本来はホストアプリ側で更新する(UPDATE発行する)かどうか判断するべきだと思うけどな ありがとうございます。 仕方ないので where ・・・ and (binary_checksum(項目1)<>binary_checksum(@項目1) or binary_checksum(項目2)<>binary_checksum(@項目2) ・・・) という風にやりました。 HashBytesにしなかった理由は、項目1つならコンフリクトの可能性が低いと判断したためです。 (演算の軽いほうで) SQLServerを使用したいと思っているのですが、全くの無知なので教えて頂きたいです。 現在、accessを使用しています。 接続人数は3人(3台)で、バックエンドデータを1つ作成しフロントエンドを3台に配布してリンクテーブルを使って使用しています。 最近、同時接続時にクエリ実行が遅くなってきて困っています。 このバックエンドデータをSQLServerに移し、ODBC接続でリンクすればクエリ速度等は解決するのでしょうか? また、SQLServerに移行したとしてもフロントエンドのacceesでは同じようにクエリやVBAでテーブルの印刷処理やクエリでの更新等も特に設定などを変えずにそのまま使用出来るのでしょうか? 初歩的なことだと思うのですがよろしくお願いします。 >>243 とりあえずやってみると良いよ 費用かからないし しかし今時こんなが環境あるんかな 20年くらい昔によくあったやつ >>243 アップサイズは全部が全部改善するとは限りませんが基本的には改善します 下の方が書かれている様に、まずやってみると良いですよ これくらいか〜と体感できますので ODBCリンクであれば基本的にフロントのAccessはそのまま使用できます SQL Serverは文字コード、ソート順、キー、インデックス くらいは確認しておいた方が良いですよ >>244 >>245 有り難うございます。 バックエンドをSQLServerに移行すると、フロントエンドでのVBAやクエリでの処理が今まで通り使えるのかが分からずに悩んでいました。 基本的には、バックエンドがacceesファイルからSQLServerに替わっても、特に編集し直すこともなくフロントエンドを使用することが出来るで大丈夫ですか? >>246 .mdb or .accdbでODBC接続なら編集不要だと思うけど SQL SERVERの照合順序は気を付けて 照合順序はアプリ側の実装に依存するから自力で調べて >>247 助言有り難うございます。 accdbなのでそのまま使えそうです。 とりあえず、SQLServerをインストール、accessデータをインポートしODBC接続までしました。 何故かテーブルデータをフロントエンドのaccessで編集出来なかったのですが、主キーが設定されてないのか、ファイアーウォールがまだ未設定だからなのか調べ中です。 疑問なのですが、 10万件のデータがあり、1件のデータを更新したい為に、単純な更新クエリを作成したとします。 単純な更新クエリなので抽出や選択もなく、10万件の全てのデータが更新されます。つまり9万9999件は無駄な更新です。 これをaccessデータのリンクテーブルではかなり時間がかかりますが、SQLServerでのリンクテーブルでは数秒で処理が終わるほど変化があるのでしょうか? それとも、このような無駄なクエリではあまり速度は変わらず、クエリ自体を考え直すべきなのでしょうか? >>248 テーブル編集はSQL Server Management Studioを使うか、DDL直接投げるか 単純なUPDATEなら10万レコードだろうが一瞬で終わるよ(※データ量次第) >>248 昔のAccessしか知らないけど 主キー無い場合はテーブルリンク作成時にキー項目選択するとかだったはず 当然可能なら主キーは設定すべきだけど 「9万9999件は無駄な更新」ってのが意味不明 何万件あろうが更新対象が1件の場合は1件しか更新しないよ その場合の更新は文字通り一瞬で終わる >>249 フロントエンドのフォームでテーブルのデータは編集出来ないのでしょうか? >>251 私の勘違いでしょうか。 いつも日報等で更新したいデータはカレントレコードの1件なのですが、更新クエリを使うと〜万件(全件)のデータを更新します、と表示されて、数分かかります。 クエリはフィールドAが空白ならフィールドBに"合格"の文字、フィールドAが空白以外なら"不合格"の文字を入れる、というクエリです。 これでは全レコードがクエリの対象になっていると解釈すべきですか。 >>252 テーブル開いてデータ変更できるよ 更新権限のないユーザーで接続してると思う >>252 このロジックだったら全件更新だよ 以下なら2件の更新になるよ それでも時間かかる場合はAとBのインデックスを作成すれば一瞬で終わる Aが空白でBが合格以外の場合は、Bに合格を入れる Aが空白以外でBが合格の場合は、Bに不合格を入れる >>252 > いつも日報等で更新したいデータはカレントレコードの1件 そのレコードを抽出する選択クエリを作成すればいいだけじゃね? >>252 >全レコードがクエリの対象になっていると解釈すべきですか どんなクエリ(SQL)流したかとどんなテーブル(インデックス)だったか分からんと分からん が、全件読み込んでる可能性が高いなぁ >>254 クエリの検索条件にACCESSの関数入れたりしたら全件取得するかもしれんぞ メインはサーバ側の話じゃなくてACCESSの動作の話だし ACCESSのスレ探すが作るかして移動したほうが良いんじゃね 皆様有り難うございます。一度クエリを見直してみます。 色々と調べたのですが、単純なフロントエンドをaccess、バックエンドをSQL ServerでODBC接続では、 クエリ等の処理はサーバー側でななくクライアント側で処理されるのであまり速度の恩恵はないと見たのですが、やはりそうなのでしょうか? これをサーバー側で処理する場合、かなりVBA等の手直しが必要なそうですが、そこまでいくと素人レベルでは難しそうです。 >>257 SQL文の実行はAccessではなくSQL Serverだよ >>254 で改善できると思われ >>259 有り難うございます。 SQL文はSQL Serverで処理されるのですね。 今の解釈としては accessのみのリンクされたデータベースでは、処理は全てクライアント側の仕事になりネットワークトラフィックが膨大になる。 SQL ServerとのODBCのリンクテーブルでは、SQL文をSQL Serverに渡し、SQL Serverが処理を行い、その解をクライアントに渡すのでネットワークトラフィックが少なくてすむ。 という理解で大丈夫でしょうか? 今までクエリ処理が重かったので、VBAを使ってきたのですが、出来るものはクエリに変えた方がいいのでしょうか? アクセスでodbcリンクテーブルを使うとデータが多いと遅いから 更新ない一覧表示とかの時はパススルークエリ使ったほうがいいと思うわ >>260 >SQL文をSQL Serverに渡し、SQL Serverが処理を行い は正しいんだが、実行する内容によって、まずACCESSがどんなSQLを発行するか その結果を受け取った後にどんな処理をするかによるので >ネットワークトラフィックが少なくてすむ とは限らん >>254 で言ってるように、検索条件にACCESSの関数入るような処理だと結局ACCESS側で全件取得して検査するかもしれん なんにしてもACCESSの話だからこれ以上はどっか移動しろ 「上位200行を編集」で表示されたデータを全選択してコピーすると 選択したデータにはあった括弧などの文字が欠落してコピーされる」みたいになバグがSqlServerにあると聞いたのですが 本当なのでしょうか?(例えば"(ABC)"を選択してコピーし、メモ帳などに貼り付けると"(ABC"になってたなど) VB6からSqlServerに接続する時はoo4oとかいうのを使うんだっけ? >>267 そうだった、オラクルだったw 10年以上前(受託開発やってた会社の正社員時代)に使ってたからすごくなつい気分になったよ、ありがとう。 そんな俺も今じゃ客先常駐のしがない派遣社員・・・orz SQLServerはStandardとEnterpriseのEdition機能差が酷すぎるわ 碌に新機能使えないならStandardなんて名乗らずにLiteとかにしろよと おれは C#,C++, PowerShell 辺りが多い Javaと聞くといつも風呂釜洗浄剤を思い浮かべてしまう >>277 vba sql-server でググれ >>277 ado(activex data object)でやってる マスターの更新とかデータのセットや取得はエクセルでやったほうが楽チン OLEDB廃止だったはずだけど、いまだにADOで接続できるドライバあるのか まあ、OLEDB-ODBCで行けるっちゃいけるんだろうけど 現在2012にて動いている環境を2014に移行させようと思っています。 データは毎夜間にbcpコマンドを使って取り入れており、そのコマンド・フォーマットファイル自体は既存のものを流用予定です。 で、実際に動かしてみると2014のみ SQLState = 22005, NativeError = 0 Error = [Microsoft][ODBC Driver 11 for SQL Server]キャストした文字コードが無効です。 が2レコード出ました。原因のレコードは突き止めたのですが、問題は分からず。 いろいろ試すと以下の事が分かりました。 ・datetime2を使用しているカラムが怪しい? ・2レコードのうち片方のレコードを削除すると全レコード取り込みOK ・問題の1レコードの位置を最下部に移動して保存し直しすると全レコード取り込みOK ・問題の1レコードのdatetime2の最下部を1桁切ると全レコード取り込みOK この件に関しては対応方法はあるのですが、そもそもの原因が分からないのは気持ち悪いです。 何か思いつく事はありますでしょうか? >>281 暗黙の型変換かなあ bcpじゃないけどバッチ処理で値によって引っかかって 手前側でcastして明示的に型変換かけてから突っ込んだことがあるな 1レコード削除したら動くとか、ケツに持ってったら動く とは整合性取れないけども 問題のレコードの末尾にエスケープコードか何か入ってるんじゃないの? NVARCHAR内のNULL文字(NCHAR(0))を検索または置換する方法はありますか? LIKE '%'+NCHAR(0)+'%' REPLACE(name, NCHAR(0), '') 等を試してみましたが、だめでした。 >>286 正しいやり方かどうかはわからんが select * from table where name like N'%' + nchar(0) + N'%' collate JAPANESE_BIN で検索できたよ SQLサーバっていまだにNとかncharとかcollateとかいるのか >>290 あ、そうなの? 最近PostgreSQLしかやってないから、他DBがどうなってるのか知らない 1回目もクエリだけやたら時間がかかるっていう経験ないですか? 2回目は速い 改善する方法あったら教えてください >>292 まずは、やたら時間がかかる原因を調べる。実行計画を見るとか。 そういうクエリ自身の問題ではない場合で、以下にあてはまるのなら、0回目のクエリを発行してデータをキャッシュにのせればいい。 (0回目:データベース起動後に重いクエリを実行するとか、テーブル全体を読んでキャッシュにのせるとか) ・単に対象データを物理ディスクから大量に読む必要がある ・なおかつ何回も類似クエリを発行する必要がある ・1回目が遅いのも改善したい キャッシュミス多発なら、キャッシュサイズを拡大する。 ハード性能的に無理なら、より性能の良いハードに乗り換える。 今調べたら、Windows Serverは余裕でTBの領域に入ってるな。2016でmax 24TB。 メモリは32GB*4の128GBで17万程度。 ストアドにしたって、データのキャッシュミスは減らんと思うが コンパイル時間で1回目だけやたら時間がかかるとか、どんな複雑なクエリ書いたらそうなるってんだ >>297 単にディスクからの読み込み量が多いだけでしょ 場合によっては、その読み込みが不要な場合もあるから、1回目のクエリから高速化できかもしれん >>298 データがキャッシュにヒットする以外に ディスクからの読み込みが不要で高速化できる場合の具体例をあげてくれ >>299 説明不足ですまん。 ディスクからの読み込みがゼロになるということじゃなくて、不要な読み込みがなくなるかもという話。 例えば、 ・インデックスがなくseq scan発生 ・インデックスはあるがクエリがまずくてインデックスが使われずseq scan発生 とか。 >>300 それストアドにしたって解決されないわけだが むしろ実行計画の生成タイミングで悪化する可能性もあるんじゃね SQL Serverのストアドがいつ実行計画立てるかしらんけど >>301 ストアドは関係ないよ クエリの内容そのものに問題があったり、indexを作ったりしたら読み込みページ数が減るかもねという話 なので、まずは実行計画を見るところから始めましょうということ 舐めるデータが多くて、初回はハードディスクから、2回目以降はキャッシュされたメモリーから だから速度が違う ストアドにすることで、コンマ何秒かは改善するかもしれないが、その程度 あとインデックスを見直すか ストアドストアド言ってる人は、90年代に生きてるんですかね >>305 実行時間短縮が目的でストアドを使う奴はいないだろうね 数百KBレベルのクエリなら、parse->palnningでコンマ何秒かかかるかもしれん >>306 関係ない事を言うのに俺にアンカつけんのやめてもらえんかな 俺までバカに見えるやろが >>308 >>305 がバカな発言だと思ってないんだw >>309 だからなんだよ? お前がそう思ってる事が今なんか関係あるのか? バカしかいないのかここは >>310 > だからなんだよ? >>305 みたいなマヌケなレスするなってことだよ そんなこともわからんバカなの? >>305 いつまでも暴れられると困るので。 > 今どきはストアド使わんのがトレンディなんか? そういうトレンドはありません。 まあしかし、ORMの普及や回線速度の向上とかでストアド不要論が優勢な流れはあるかと 昔はトラフィック減らして速度向上させるためにストアドって流れはある事はあったからな >>311 だから関係ないレスでアンカつけんのやめてもらえんかな 俺までバカに見えるやろが >>313 SQLSeverと親和性高いC#がEF推しているのを見ると不要論が優勢でも不思議じゃないな >>313 ,315 ORMやEFが広まれば、よりストアドプロシージャ・ファンクションの需要が高まる気がするが。 ドメインロジックはサーバ側で実装し、クライアントはそれを使用するだけというスタイル。 そんな思想があったらRailsなんぞ流行らんわ 何処の時空の話だよ >>318 まぁ、RailsだろうがEFだろうが、データをどかっと取ってきて、クライアントコードで ごりごりドメインロジックを実装するような層には関係ない話かな。 そんな話じゃねえよ EFが何しにPOCOなんての売りにしてたかって話だ >>320 つまりは、 > データをどかっと取ってきて、クライアントコードで > ごりごりドメインロジックを実装する ということだろ? POCOメインのプログラマには関係ない話だよ。 そんな話じゃないなら、どんな話なんだ? DB側でスキーマ書いて処理も書いてってのが古い思想という話をしている 開発スピードが無闇に上がってスキーマ変更朝令暮改でって今時はな >>322 > DB側でスキーマ書いて処理も書いてってのが古い思想という話をしている なるほどね。 でも、ドメインロジックをデータベース側に寄せるか、クライアント側に寄せるかという問題は、 今でも存在する。ふるいも新しいもないと思うが。 > 開発スピードが無闇に上がってスキーマ変更朝令暮改でって今時はな それこそ、データベース側にドメインロジックの実装を寄せた方がいいのでは? 例えば、2003年のMartin Fowlerのブログポスト: 『ドメインロジックとSQL』 http://bliki-ja.github.io/DomainLogicAndSQL/ ここに書かれていることは、全然古いとは思わない。 逆に、自動生成されるコードをメインに使うようになる場合は、ドメインロジックを ストアドファンクションで実装してViewにした方がいい場合も結構あると思うんだが。 昔々のウォーターフォールで上流で設計決まる時代ならそれもよかろうさ だが今はデータ構造から卓袱台返される その時アプリとDB両方に手ぇ入れるのと アプリだけで済むのとどっちが早いか? 自明だろ DB側でごりごり書いたストアドって、InMemoryでUnitTestできるのかい? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる