Microsoft SQL Server 総合スレ 11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Microsoft SQL Server (Transact-SQL) の総合スレッドです。
・Microsoft 公式サイト
http://www.microsoft.com/japan/sql/
過去スレとかめんどいから誰か適当に貼って Committed bytesの適正値を考えると、メモリ2GBならIISとSQLserver合算で1GB未満、できれば600〜800MBくらいかなあ感覚だけど
IISとSQLserverで上限設定しときゃサーバーが不安定になるのは抑えられると思う
素直にメモリ増強するのが一番いいけどね >>147>>148
レスありがとうございました。
余裕をみて4GBくらいでVPS契約してみます。 >>149
個人利用でやる分には2GBでもいいと思うよ
会社のパソコン(Windows7の32bit、メモリ2GB)にSQLserver Developer EditionとIIS入れてて普通に動作する
Officeとかも使うとやっぱきつくなるんで普段はサービス停止してるけどね 質問です。
先日、知り合いの店でデータベースリストアが勝手に走ったのですが
何が原因なのか不明な状態です。下記が一部ログになります。
The database '*****'' is marked RESTORING and is in a state that does not allow recovery to be run.
分かる方いらした教えてください。 ある特定のテーブルで大量の件数をDeleteする時だけ
異常に時間がかかるんですが何故だかわかりますか?
ググってもイマイチ分からんです
Delete From TABLE Where PK<****
みたいな単純なやり方なんですが…
エスパーの方教えてください >>153
断片化が走りまくってるとか?
Insertするときもプライマリキー張ってると徐々に遅くなってくしそれかも
一回リビルドインデックスしてからやってみたら変わらんかなあ
sum関数でInt型の限界越えてオーバーフローしたんだが、実行プラン次第でオーバーフローしたりしなかったりするのは仕様?不具合?
2008r2から2014のsp2に移行しようとして本番データで動かしたらエラーなりやがった
MSに問い合わせる前にバグか仕様かのあたりつけときたい >>153
SELECTするときも時間がかかってる? あとでrollbackされたときに備えて、delete予定データをいったんtempに吐いてるから
データ数が多いと死ぬほど遅い
生かすデータだけ別テーブルに吐いてtruncate tableして別テーブルをリネームしたほうが早い場合もある >>156
そんな初心者みたいなアドバイスするなよw >>156
1000万件中10万件だけ残したいとか
そういう時はそっちの方がいいよね
truncateは本当に爽快 だけど、>>156 以外に方法ないんだな、これが
あと、1回あたりのdelete数を減らしてやって(その分、何回も回して)
1トランザクションあたりのロックを多少なりとも緩和するか 自分の場合、1億レコードが1000万件を退避させるとき
SET ROWCOUNT 指定して、小刻みに削除してる
(トランザクションログが一杯になるのを防止)
それでも平気で一晩とかかかるが ・復旧モデルを完全から単純にする
・テーブルロックを明示して削除する
・クラスターインデックスをやめる
・インデックスをドロップしてから削除
全部やって遅いなら、ハードを速いのに変えろ 具体的には何も言えないチキン ⇒ ID:mgIvH7zu パーティションテーブルにできるならそれにしちゃえば?
あれならパーティション単位にトランケート 出来るらしいが truncate table に where 書けたら解決なのにな
それか、delete に「Rollback不能で構いませんから速くやってください」って with 句を準備してくれるか ロールバック不能で良いっていっても、その文でのアトミックは保障しないとだめだからなぁ >>154
これの下の質問書いた者です
不具合ではなさそうなのがわかったのですがどうしたものかと質問です。
select 番号,sum(金額)
from テーブルA
inner join テーブルB on 〜
inner join テーブルC on 〜
inner join テーブルD on 〜
where 〜
group by 番号
これの実行プランがテーブルDとの内部結合前にgroup byとsumしててInt型の上限越えてしまいました
テーブルDとの内部結合を先にやってくれてたらそのデータが除外されて問題なかったのにっていう結果
whereとjoinとgroupby って優先順位特にないんでしたっけ
確実なエラー回避方法がBIGInt変換くらいしか思い付かない >>171
deleteも結局はページ単位の処理になるからね、消すだけじゃなくページ間のインデックスも保持しなきゃとかいろいろやってるから
全部いらないから細かいこと抜きでってできるtruncateのようにはいかないよ >>173
SQLは手続き型言語ではないので実行順序はオプティマイザが決めるってのが原則
ある程度はオプティマイザへの指示をクエリヒントって形で出せるけど
Dの結合を先にするようにサブクエリ書いてFORCE ORDER指定で行けるかもしれんが
そんなSQLは保守性わるいし、基本的にはどんな実行計画でもエラーにならんようにしろとしか >>163
1億レコードって物凄い大きなDBですか?
どんなシステムなのか見当もつかない >>176
誰もが知ってる会社のシステムならその程度は珍しくもないけど。 >>178
むしろお前にどんな仕事してるのかを聞きたいわ スカート捲ってもらって股間の香り嗅ぎながらチンポ握ると五分で発射寸前だよ。
二十歳ぐらいの女の子のナマパンツに顔を埋めて拭き取り漏れのお尻の穴のリアルな香りを嗅いで好き放題シコる。
この状況で一時間持つ意味が分からん。 更新しなくてSELECTだけのストアドがあります。
パラメータは3つです。
返ってくる行は30行程度で
クエリエディタから実行すると精々1〜2秒で戻ってきます。
クエリエディタでやってることと同様のものを
System.Data.SqlClient.SqlCommand で作って ExecuteReader してやるんですが
ExecuteReader が終わるまで15秒ほどかかります。
条件のよいとき(クエリエディタで1秒のもの)でも8〜9秒です。
いったい何が原因なのでしょうか。 解決しました。
ALTER DATABASE データベース名 SET ARITHABORT ON
で算術アボートを有効にしてやったら、クエリエディタと同じになりました。 ちょっと違ってました。
ALTER DATABASE データベース名 SET ARITHABORT ON
することで、クエリエディタと同じ速度になりましたが、
ADO.NET のときと同じ速度に、つまりは遅い方に揃ってしまいました。
ALTER DATABASE データベース名 SET ARITHABORT OFF
に戻したうえで、SqlCommand を投げるごとに
先に SET ARITHABORT OFF しておくと、早いクエリエディタと同じ速度になりました。
ゼロ割算の対策はしてあるつもりだし、むしろ NULL で進むよりエラーにしてもらったほうが嬉しいので
これはこれでいいのですが、全ての SqlCommand に埋め込まないといけないのか・・・ >>181-182
テーブル変数とか使ってる?
実テーブルからだけのselectでも発生してる? テーブル変数を使ってたんですが、作業表(#〜)にしても一緒でした。
中身一緒かもしれませんが。 >>185
テーブル変数つかうと、行数を正しく判定できないで遅いプラン作る事があるってのは聞いたことある
selectしてるとこにRECOMPILEヒント入れるとマシになるかも
当然リコンパイル分のパフォーマンス劣化はあるけど、遅いプランとどっちがマシか比べて ストアドの中のselect〜の末尾に option(RECOMPILE) 追加するんですよね?
試してみましたが、全く効果なく、事前の SET ARITHABORT ON を外すと元通り劇遅になりました。
ConnectionStringで SET ARITHABORT ON を指定できたらいいのですが。。。 ARITHABORT OFFで遅い実行計画つくることがあるとはMSDNにも書かれてるけど
実際にそれが原因で問題のある実行計画作られたのは見た事ないなぁ
executeにWITH RECOMPILEつけても同じ?
これでダメなら、自分で適切なヒント付けてやればいいんだけど
そもそも実行計画の問題じゃない気もしなくはないな テーブルに単価のフィールドを持ってなくて、そのかわりに金額÷数量を単価とみなすビューを作ってあるんです
金額/nullif(数量,0) as 単価
それ利用してるもんだから、ゼロ割算の関係だとしたらビンゴなんですよ。 SET NOCOUNT ON してる?
ほんとにSET ARITHABORT の問題なら、ストアドの中でSET ARITHABORT ON すれば良い >>191
SET NOCOUNT ON は基本やってます。
ストアドの中で SET ARITHABORT ON 明示してもいいんですか。
とりあえず今回気が付いたもの以外にも、気が付かないだけで潜在的に遅いものがありそうな気がしてまして
かつ、ストアドでなくソースの中でSQL吐いてるのもあって、
CreateCommand する直後で全て SET ARITHABORT ON したほうが良さそうな感じ。
http://www.sommarskog.se/query-plan-mysteries.html
が詳しいようです。 いま注目してるストアドを相手にしたときは
SET ARITHABORT OFF で16秒
SET ARITHABORT ON で2秒
くらいの違いがありました。
続けて何度か回しても結果は大差ないので、キャッシュの関係もなさそうだし・・・ >>192
そこも、基本的にはオプションが違うと実行計画が違うよって話
実行計画うんぬん以前に、オプションで結果変わってるし
そのコードじゃゼロ割りの対策してないしw
キャッシュってのは、クエリプランのキャッシュのこと
データキャッシュとは別だから、何回回しても大差ないよ >>194
> そのコードじゃゼロ割りの対策してないしw
ど素人は黙っとけ col1 nvarchar(100) Primary Key
col2 int Primary Key, IDENTITY
con3 nvarchar(100)
の場合に
col1,col3の値を指定してinsertのつもりが、間違えてUpdateを実行したら
col1の値に等しい全ての行のcol1, col3が全部同じ値になってしまったのですが
そういうもんですか? どうやったらInsとupd間違うんだろう
where句なしで実行ってこと?
ORマッパーみたいなツールの話だろうか 言ってる意味がわからないけど
col2がidentityならそれでユニークは保障されるから
col1とcol3が全部同じでもなんの不思議もない
どう間違えたらinsert文がupdate文になるのか知らんが
そういうSQL流したんだろ col1 col2 col3
Aさん 1 データ1
Aさん 2 データ2
Aさん 3 データ3
Bさん 4 データ4
Cさん 5 データ5
Cさん 6 データ6
が
col1 col2 col3
Aさん 1 データ1
Aさん 2 データ1
Aさん 3 データ1
Aさん 4 データ1
Aさん 5 データ1
Aさん 6 データ1
こんなふうになりました。 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) update 表名
set col1 = 'Aさん',col3 = 'データ1'
以外でこうなるSQLを考えるクイズの時間です >>196
つか、そもそもそのテーブルのPKがおかしい。 >>201
複合主キーじゃあないの?
どのあたりがおかしい? >>202
普通 Identity だけにしないか?
複合にする意図がわからん clo2は単にユニーク保障のためだけで、実質はcol1+連番がキーなんだろ
そういう意図を表すためには複合主キーで良いんじゃね
あくまでcol2単独の検索はしない前提たが
インデックスがcol1からの(クラスタ化)インデックスひとつで済むってメリットもあるかもしれんw >>204
> そういう意図を表すため
いやその「そう言う意図」がイミフなんだが insertのつもりでupdateしてしまう手法のことか? >>196 のような手法
って言うのが Identity + 他の何か を複合キーにすると言う話なら俺は見たことはない
むしろ >>207 の言ってる方がまだあり得る 調べものしててmsdnのサイト見てたら2016の次にVNextとかいうのがでてた
早いなあと思ってたら2016のSP1が既に出てて驚愕
Microsoftなんか焦ってる? VPSでSQL SERVER EXPRESS 2016を使う場合には最低限どんなスペックが必要かな?
運用中の人がいたらCPU数、メモリGBなどアドバイスが欲しい。 規模も用途も書かんのなら、公式の動作環境以上の回答があるとは思えんが カーソルのFAST_FORWARDって内部で何してるの?
INSENSITIVEやFORWARD_ONLYだとmaxdop数分のスレッドでカーソルオープンしてるのに、FAST_FORWARDだと1dopになる
クエリは単一テーブルのselect文で、group by、order by句がある
msdnのカーソルのとこ読んだけどわかんなかったよ
ちな2014のsp2です 2014でレプリケーションができないです
配布元のデータができないです
リカバリする方法ないでしょか? sql サーバーってマルチコアcpuで実行すると並列で処理されてレスポンス速くなったりするの? レスポンス変わるだろうけど、ディスクアクセスの要素のほうが強くて条件次第では大幅に、とはいかなそうね 2016 express版を使っています。
20万件くらいのテーブルから全件をorder byして取り出すだけで
20秒くらいかかるんです、そんなもんですか? >>223
速くする方法を教えて下さい。
データは1時間に一回くらい更新されるので、例えばその時にorder byした
データを作成しておけば良いかなあと思うのですが、そういう方式で速くなりますか? >>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の照合順序は気を付けて
照合順序はアプリ側の実装に依存するから自力で調べて ■ このスレッドは過去ログ倉庫に格納されています