- 締切済み
SQLServerでSELECTを実行すると仮想メモリがなくなる
bin-chanの回答
- bin-chan
- ベストアンサー率33% (1403/4213)
table1のレコード件数はどのくらいあるのでしょうか？ 索引(INDEX)が無いけど件数が多い、等の場合、検索に「時間がかかる」のかな？
関連するQ&A
- SELECT実行中にINSERTしたい
テーブルTに対し、データ抽出に数分かかるようなSELECT文を実行しているとして、 そのSELECT文の実行中にInsertしたらどのような挙動になるでしょうか。 （INSERTした瞬間にエラーが発生する？） また、SELECT文の実行中にInsertしたら、 「SELECT文が実行終了するまで待って、そのあとにINSERTする」 という動きにしたい場合、どのように設定（or SQLを書けば？）すればよいでしょうか。
- ベストアンサー
- MySQL
- ACCESSからSQLServerのデータを取得したい
SQLServerが利用できない環境にデータを持っていくため、以下のようなシステムを考えております。（テーブルのリンクは不可・手動でのデータのエクスポートは不可） 1.ACCESSのフォームに「データベース名」「テーブル名」を入力し、実行ボタン押下 2.ADOでSQLServerに接続 3.指定のテーブルと同じ構造のテーブルをACCESSに作成 4.SQLServerのデータをACCESSにINSERT ここで質問なのですが、ACCESSは自分のデータベースとSQLServerのデータベースに同時に接続できますか？ 同時接続した場合のACCESS/SQLServerの書き分けはどのようになるのでしょうか。
- ベストアンサー
- その他(データベース)
- T-SQLとACCESSクエリのSELECT分内のif文の利用について
お世話になります。 ACCESSクエリからSQLServer2005のストアドに移行を検討中です。 ACCESSクエリではINSERT INTO時のSELECT内にIIF文による条件分岐が使えたのですが、T-SQLでは、INSERT INTO時のSELECT内にIF文やswitch文は使えないのでしょうか？その場合、どのようにすれば宜しいでしょうか？ 例＞ ACCESSクエリでは以下のようにかけると思うのですが・・・ INSERT INTO Table1 (Pコード,単価) SELECT Table2.Pコード,IIf(Table2.Check定価=1,Table2.定価A*Table3.値引率,Table2.定価B*Table3.値引率) FROM Table2 RIGHT JOIN Table3 ON Table2.Pコード = Table3.Pコード; 宜しくお願いします。
- ベストアンサー
- SQL Server
- SQLServer2000のselect文で
SQLServer2000のselect文で select count(*) from Table を実行するのに３０秒以上かかってしまいます。 データ数は１００万件もありません。 全件数を取得するのになぜこんなにかかってしまうのでしょうか？ 主キーはVarcharの５０バイトです。 こんな単純な文でこれだけかかってしまうのは、 DBの設定が悪いのでしょうか？ それともPCの性能が悪いのでしょうか？
- ベストアンサー
- SQL Server
- SELECT文の二段重ね
次のSQL文を実行します。 create table1 (id, english) insert table1 (1,"foo") insert table1 (2,"bar") create table2 (id, japanese) insert table2 (1, "ふー") insert table2 (2, "ばー") SQL文法としては誤ってますが、成功したとします。 いま、select id from table1 where english = 'foo'; で1が得られます。 いま、select japanese from table2 where id = 1; で"ふー"が得られます。 これを一つのSQLite3のselect文で実現できないでしょうか。 select japanese from table2 where id = (select id from table1 where english = 'foo'); で良いですか？ カテゴリ選択にSQLiteが無いのは、人気が無いからですかね。
- ベストアンサー
- その他(データベース)
- SQLServerでREPLACE/SELECTができるか？
My-SQLでは以下のSQLにより test01というDBからtest02というDBへ データをinsertすることができると思います。 また「insert」ではなく「replace」にすることで 同一キーの場合エラーにならず置き換えで データを登録してくれます。 ======================================= insert into [test01].dbo.test_table select * from [test02].dbo.test_table ======================================= そこで上記の「replace」を同じように SQLServerでできないか知っている方が おられたら是非ご教授いただきたく。 よろしくお願いいたします。
- 締切済み
- SQL Server
- SQLServerのロック？について
お世話になっております。 早速ですが、質問させていただきます。 ASP＋SQLServer2000で社内システムの作成などを行っております。 ASP上から社員がデータを打ち込んでいるシステムがあるのですが、同時にSELECT、UPDATE、INSERT、DELETEを一つのテーブルで行っております。 その際、SELECTとUPDATE、INSERT、DELETEの処理がかぶると画面が固まったように処理が長くなります。 自分でわかる限りの原因としては検索レコードは10万件くらいからやっているのですが、SELECTで検索中にINSER、UPDATE、DELETE処理がくるとウエイト状態になり、異常に時間がかかってしまい、タイムアウトしてしまっています。 INSERTやUPDATEが処理かぶっても特に処理はとまらないのですが、先にSELECT処理していてINSERTやUPDATE処理がくるとまったく動かなくなってしまうのです。 こちらの原因とか少しでもわかる方いらっしゃれば、お知恵をお貸しください。
- ベストアンサー
- SQL Server
- SQLの実行速度
XMLを解析し、テーブル内を検索するシステムを 作成しているのですが、 ストアドプロシージャ内でSQL文を作成し実行するのと ASP.NET などからSQL文を作成して実行するのとでは、 実行速度に差はでるのものなのでしょうか。 ・SQLServer 2005 ・SELECT の対象テーブルは2～3つのテーブルをINNER JOIN して使う。 ・検索対象の列は実行のたびに異なる。 よろしくおねがいします。
- ベストアンサー
- SQL Server
- SQLServer2005 でSELECTを実行した結果（クエリ結果）がSQLServer2000の時の２倍の大きさになる
SQLServer2005 でSELECTを実行した結果（クエリ結果）をファイルに出力したところ、同じデータベース項目をSQLServer2000 でSELECTした結果の２倍程度の大きさになる。 ファイルダンプを採取して中身をみたところ、UNICODEでファイル出力されており、すべての半角文字が２バイト表記されていたため、SQLServer2000（こちらは半角文字は１バイト）のほぼ２倍の大きさになっている事が分かりました。 SQLServer2005 でSELECTを実行した結果（クエリ結果）を半角文字は１バイトで出力する良い方法をご存じの方、ご教示いただけないでしょうか？
- 締切済み
- SQL Server
- SQLServerで更新ができない。
環境 Windows NT SQLServer 7.0 SQLServerのクエリアナライザ等で参照（select文）は成功するのですが、 更新（update文やinsert文）を実行すると以下のエラーが発生します。 解決方法がわかる方いましたら教えてください。 サーバー : メッセージ 6、レベル 16、状態 1、行 4 指定された SQL Server が見つかりません。
- 締切済み
- その他(データベース)
お礼
その後同様の現象は発生しておらず、回答もないようなので締め切らせていただきます。 bin-chanさま、アドバイスありがとうございました。 （原因不明のままなので、ポイント発行は見送らせていただきます。ご了承ください）、
補足
現象が発生していた時点では、件数は１件でした（動作確認段階なので）。 索引はないです。 実は質問をした後、SQLServerに詳しい人が帰ってきたので見てもらおうとしたのですが、なぜか正常に動くようになっていました。 以後、現在まで再発していません。見てもらった人も、話を聞いただけでは原因はわからないと言っていました。 ただ、以前にも同じシステムを別サーバで動かしていて同じ状態になり、他のサーバ利用者に迷惑がかからないよう、サーバを変えたという経緯があります。その時も結局原因は不明でした。 ですから、またいつ同じ現象が発生するか、ちょっと不安です。