Microsoft SQL Server 総合スレ 11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Microsoft SQL Server (Transact-SQL) の総合スレッドです。 ・Microsoft 公式サイト http://www.microsoft.com/japan/sql/ 過去スレとかめんどいから誰か適当に貼って じゃやっぱりWinマシンを買うところからってことですね >>405 使えないということと書けるの違いはどう理解すればいいですか? >>406 SQLとSQL serverの違いはわかってる? んと、SQLはプログラミング言語で SQLserverはMS社のデータベース 何に混乱しているかというと SQLserverのWikiを読むと言語はc,c++,c#とある でも他の本ではSQL自体をプログラミング言語と書いてある そこでちょっと混乱 https://ja.m.wikipedia.org/wiki/Microsoft_SQL_Server その記載ってSQL Serverを作成した言語の話じゃないかな >>411 そういうことなのですか ありがとうございます ではもとい、Winマシンを買うのは必須ですね 仮想環境入れて、そこでWindowsを動かすという方法もあるけれど どういう目的で使うのか、どの位の頻度で使うのかにもよるだろうね >>413 会社は普通にWindows機なんで、macは自宅学習用です プログラミング自体初めてなので家でも勉強しようと思って macはバカが使うものだからバカになりたくなかったら今すぐ捨てた方がいいね >>414 MacBookPro15なら、そこそこパワーがあるしMemoryも乗っているから 仮想環境でそれなりに動かす事はできる それ以外のときはBoot Camp使って、起動を切り替える方が良いかもしれない SSDだろうから切り換えしてもそれほどストレスにはならないと思う >>419 >>420 ありがとうございます macにWindows入れること検討してみたいと思います macはモニターの色は綺麗だし普段使いには満足してますが、office系ソフトはショートカットが使えなくて戸惑うし一長一短ですね 家に仕事持ち込むわけではないので、まずは会社のWindowsで慣れてから再度考えようと思います sqlを練習する程度ならmysqlでもいいんじゃないか? Macでも動くし。 >>422 そうなんですか!? 前に調べてた時macでも使用可なのがあった記憶がベースで今回の質問に至っておりまして… それがmysqlだったのかもしれません ありがとうございます! まずはそこからやってみます >>423 そんなに驚くなよ。 sql server expressはwindows専用だが それ以外のフリーなdbソフトは大体はMacでも動くんじゃないか?俺はMac持ってないが SQLServerのデータファイルの自動拡張がタイムアウトしたってイベントログ出てるんですが 自動拡張時のサイズ小さくすれば解決するもんなのかな? 書き込みが頻発するとディスクアクセスがボトルネックになりそうなんだが そもそものタイムアウトが発生するところをケアすべきよね やっぱ >>425 自動拡張の初期値はファイルサイズのX%なのでサイズがでかくなるにつれ拡張サイズも増えて処理がタイムアウトするから拡張サイズは固定値にした方が良いよ ログファイルじゃなくてデータファイルならそもそものデータ見積もりが誤っているという話もあるが すんません、 「やってみたら?まぁ上手くいくわけないんだけどなwせいぜい絶望してファントム生んでろw誰もエンゲージしねーけどw」 って事かと思って保留してました。 実践していただいた方もいて、助かりました。やってみます。 自分のPCなんで最悪HDDのイメージ取ってから試せば何とでもなるんですけどね。 試行錯誤できる環境を作る時間がなくて。 でもHDDの空き容量もなくて。 そして人生の余裕もない。 もう死にたい。全てが嫌になった。 SQL2014の自動拡張で質問です。 例えば10MBまたは100MBと指定して拡張されたタイミングまたはログというのは何処で確認できるものでしょうか? SQL2008だと「ディスク使用量」レポートで確認できるという記事を見かけて 2014環境で確認しましたが思うような結果が得られませんでした。 復旧モデルが単純だったせいなのか、2014では別のレポートで出力出来るのか判断がつきかねています。 ど素人なので的外れな事を書いているかもしれませんが何かヒント頂ければ幸いです。 SSMSで管理のSQL Serverログとか OSのイベントビューアでアプリケーションログとかになんか吐いてなかったっけ なんでちょっとMSの中の人よりの言いかたなんだよw >>429 ありがとうございます ご鞭撻頂いた項目で確認したいと思います 質問させてください。 SQLServer2008 R2で、主キーにクラスタ化インデックスを指定されたあるテーブルに対し、 主キーを指定した単純なSelect文を発行して実際の実行プランを表示させたところ、なぜか「TableScan」となります。 ・WHERE句に主キーを指定したのになぜ「Clustered index seek」にならないのでしょうか? 少なくとも「Clustered index scan」にならないのはなぜでしょうか? この点についてなにかこういうところを確認してみろという部分はありますか? もしくは実行プラン「Table Scan」でもとくに気にするところではないのでしょうか? 特にSelect結果が遅いわけではなく、1秒もかからないで結果が返ってくるので 特に現時点では致命的ではないのですが・・・ その他の状況としては以下の通りです。 ・テーブルのレコード数は数万程度。 ・もともとのこのDBはSQLServer2005で作られたものであり、バックアップから復元して互換性レベルを上げてある。 ・Indexの再構築を行っている ・別な環境で似たような状況をつくりだし、同じくSelectをしてみたところ、想定した通り「Clustered index seek」となった。 ・数ヶ月以上運用され、INSERTやUPDATEなどは繰り返し発生している 以上のような状況なのですが、 なにかわかる方がいらっしゃったらよろしくお願いします。 >>436 あのな、インデックスがあればインデックススキャンになるわけじゃないんだよ。データによってはテーブルスキャンの方が速い。それを自動で判断した結果がそういうことだよ。 >>436 UPDATE STATISTICSで統計情報を更新したり、DBCC FREEPROCCACHEで実行プランをクリアするぐらいかね 遅くなる可能性もあるから、事前確認は怠らずにね >>437-438 早速の返答ありがとうございます。 かならずしもIndex seekのほうがよいわけではないんですね。 統計情報の更新は調べてやってみることにします。 ありがごうとざいます。 数万程度ならどんな実行計画でも時間は変わらない可能性大だが、 どうしても拘束しないたらヒント文を追加すれば? >>440 ヒント文でインデックスを指定できるんですね。 これでやってみて時間がかわらなそうであれば元の状態で行こうと思います。 ありがとうございました。 1フィールドだけのテーブルがあって、その1フィールドにプライマリキーが設定されてるのを見るとなんか微妙な気分になるw クラスター化インデックスのあるテーブルってテーブルスキャンは発生しないと思ってんだが違うのか 俺の知る限り、テーブルスキャンするところはすべてクラスターインデックススキャンになるんだが クラスターインデックスのフルスキャンはテーブルスキャンと実質同じだと思うんだが、何が違うんだろ テーブルスキャンならクラスターインデックスのリーフページだけをたどれる? access単体でデータベースを作成するのと、SQLserver+Vbで作成するのは難易度はどのくらい違いますか? だいぶ前にミラーリングが非推奨の機能になっちゃったけど、これからはクラスタ作ってAlwaysOnでやるしか無いのかね 今時オンプレかよとは言わないで >>444 それだけの内容では色々分からなすぎて 双方の言語経験があるなら差はほとんどない、としか答えられない >>447 Standardのライセンス2つで安価、手軽に二重化出来ること 試しにAlwaysOn構築しようと思ったら、SQLServer外の条件で制約多くて >>449 AlwaysOnは知らんが、ミラーリングの場合、待機側はライセンス要らないよ ますますミラーリングから離れられないわな AlwaysOnは1台につき1ライセンス必要だし ミラーリングでライセンスいらないのは、完全に待機のみの場合だけだったはず ダウンタイムの短縮には役に立つけど、負荷分散には使えないぞ SQL Server絡みの地雷率が高すぎてうんざりしてきた windowsしか使えないのでこれ使いました! プログラムはよくわかんないので中身は適当です! 十数年分の滅茶苦茶に蓄積されたデータは再利用できるようにしてください! みたいのしかねえ >>457 知識の蓄積もない、Microsoftは利用者を育てることが重要だと思ってないからな。 >>458 サポート費用払う前提だがそれなりの対応してると思う 何か問題でもあったのか? >>457 はMSをディスってるんじゃなくてその利用者をディスってるんだろ むしろそんな連中でもとりあえずのシステムが組めるMS製品群スゲーって話 まあ引き継ぎとかでうんざりする気持ちはよくわかるが w >>460 とりあえずじゃないからSQLServerの地雷案件が多いんだよな 設定もろくにせずに遅くなったら魔法の言葉「MSの製品だからしょうがない」で誤魔化そうとする阿呆多すぎる >>459 日本マイクロソフトのサポートもレベルがひどい 教えてください。 SQLServer の View でトリガを使って別のテーブルの編集を行いたいと思います。 ほぼこのページの通りに書いてみたのですが、View の参照元のテーブルにレコードを追加してもトリガが実行されないようです。 https://msdn.microsoft.com/ja-jp/library/def01zh2 (v=vs.120).aspx 実際のテスト環境は以下の通りです。 ・DB: A テーブル01 ・DB: B ビュー01 (DB:Aのテーブル01を参照) トリガ01 (ビュー01に対して INSTEAD OF INSERT でテーブル 02 に情報を追加) テーブル02 (テーブル01のキー項目に関連づけて、追加項目を登録) DB:B は DB:A を参照した試験環境で、DB:B を削除するだけで後腐れなく試験環境を除去できないかな、と考えました。 DB:A のテーブル01にトリガを仕掛ければ問題なくやりたいことは出来るのですが。 ビューのトリガを動かすのには何か設定が必要なのでしょうか。 SET ARITHABORT はヘルプやノウハウ掲示板ではON推奨になってるけど、逆の場合もあるようで、とあるストアドでは パラメータ:日付指定→行番号取得→本処理 1.ADOのデフォルトでOFF: 1秒 2.SSMSのデフォルトでON: 20秒 3.ストアド内で SET ARITHABORT を記述: 20秒(1、2どちらもONでもOFFでも同じ) 4.ストアド内の記述を外し、SSMSのオプション設定でOFFに変更: 1秒 パラメータ:行番号指定→本処理 5.ADOのデフォルトでOFF: 20秒 ←これが問題だった 6.SSMSのデフォルトでON: 20秒 7.ストアド内で SET ARITHABORT を記述: 20秒(5、6どちらもONでもOFFでも同じ) 8.ストアド内の記述を外し、SSMSのオプション設定でOFFに変更: 1秒 9.その後、ADOのデフォルトでOFF: 1秒 ←解決 パラメータは後者の方が処理が少ないのに、妙に遅かったという問題 接続コンポーネントのSET ARITHABORTのデフォルトの違いによって実行プランが分かれるという話を見て、以上のことをごちゃごちゃやってたら直った でも解決法が逆 開発当時を覚えてないけど、前者は最初に実行プランができたのがADOでの実行で、後者はSSMSだったのかもしれない つまり A.先にADOでSET ARITHABORT OFFで実行→SSMSでONで実行→実行プランが分かれる B.先にSSMSでONで実行→ADOでOFFで実行→ONの実行プランが使われる C.Bを解除するにはSSMSでOFFで実行(および再コンパイル?) つまり、散見するノウハウとは逆にSSMSを常にSET ARITHABORT OFFにした状態で開発した方がいいのかもしれない ADOもSET ANSI_WARNINGSはONなので、SET ARITHABORTがOFFでも0除算エラーは出るし ちなみに、SQL Serverは2014 実際酷いのもいるけど、そういうのはむしろORACLE出身だったりするw(内部結合のビューのみでやりきろうとする信じられない低レベルもいる) SQL Serverは同一ストアド内に制御文と問合せ文が同居できるため工夫の範囲が広く、むしろORACLEよりレベルの高い技術者も多いとも聞く いずれにせよ前任者はそれを0から構築したわけで(おそらく低予算で)、前任者が悪いんでなく、引き継げない後任者のレベルが低いと考えるべき 前任者のレベルが低いと言うならむしろ引き継ぐだけでなく改善して、処理速度を数十倍〜数百倍に上げてみせるべき 復旧モデルについてなのですが、「完全」よりも「単純」の方が余計なことをしない分 処理速度自体は総じて速いという認識で良いのでしょうか? >>468 処理速度はほとんど変わらないけど、完全はトランザクションログのメンテナンスを疎かにしてトラブル起きやすいイメージ 単純でもトランザクションのロールバックはできるわけだから、ログは取ってるんだが 一括ログ可能な操作だと、単純でも一括ログ方式の最少ログしか取ってないのかな そうじゃないなら、速度的には一括ログが一番早いんじゃないんじゃね 体感できるとは思えんけど バッチ処理で大量にデータを ローディングするようなシステムではそれなりに差が出るよ BULK INSERTでだいたい20~25%くらい短縮できる >>472 完全と一括ログの比較じゃなくて 単純より一括ログの方が早いって話? >>473 単純は一括と同じでしょ そこは試してないけどマニュアルにはそう書いてるよ >>478 保守契約切れても何も言ってこないので他社システムに移行したと思ったら、単にケチってただけだったという・・・ うちの社内システムなんてSqlServer2000+VB6だぞw 安定稼働してるDBMSを変更する理由がないからなぁ ORACLEとかサポート切れたら不安しかないけど 格好の標的だね metasploitみたいの使って簡単に攻撃されるよ >>481 そういやいまだにoo4o使ってるシステムもあったw そもそもDBに不特定多数が直接接続できるシステムがまれだと思うが いやまあSQL Slammerみたいな例もあるから何とも言えんけど DBサーバそのものがネットワークに晒されてるような環境とそうじゃない環境じゃ 求められるセキュリティ強度も違うんじゃないかね >>486 DBに(社内の)不特定多数が直接接続できるのはまれだと思うがDBが入ってるサーバーに(ログインはできないけど)直接接続できるケースは多いと思うぞ 別サーバーからSSMSからは接続出来ないのに sqlcmdからは操作出来ちゃうアホな設定のDBがあったなあ >>490 技とそういう設定にしてるんじゃないか? SSMSの最新版が出ているようですが、入れると何か良い事ありますか? 病気が治って彼女が出来て宝くじに当たって出世しまくるなどいい事ずくめ Queryのウインドウでは、色付きで分かり易くクエリが表示出来ますよね。 コピペしてワードなどに貼り付けるとその色情報が失われますが、 どうにかして文字だけでなく色もコピペできませんか? >>495 文法読み取って色表示しているのがクエリエディタの機能だから無理じゃね >>495 同じ機能を持ったテキストエディタに張り付ければいいじゃん 例えば社員テーブルに複数の社員のデータを一気に追加する場合に 社員番号をキーとして、 もしテーブルに該当社員がいればUpdate、 いない場合はInsertしたいのですが、 そう言う処理を簡単にやるコマンドはありますか? >>495 「形式を選択して貼り付け」じゃないの? rich text formatでクリップボードにはコピーされてるはず その後、mergeをいろいろ試しています。 社員更新データを#で始まるローカル一時テーブルに入れておいて、 社員テーブルにマージする方針で出来たのですが、そのやり方で良いでしょうか? 調べていると、Temporal tablesと言うのもあるようですが今回のマージ処理に使うと何か良い事ありますか? 一時テーブルは大量データには向かない 更新頻度が低いならまあ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる