SQL ServerよりOracleの方が優れてるなと思った話

Oracle社は好きじゃないんだが、OracleDBは好きです。前職では、なんちゃってDBAみたいな役割だったこともあり、Oracle Master Goldも取得した。

ですが、今の会社で昨年基幹システムのリプレースがあり、そのシステムがSQL Serverだったのですが、運用フェーズに入ってSQL Serverと戯れることが多くなりました。

で、改めてOracleの方が優れてるなぁ。という話。コスト的には断然安いからその点は置いとくとして、あくまで運用担当者目線。あと、今回導入したERPのソフトに起因するのもあるけれども、つらつらと書いてみる。

基本機能

読み取り一貫性とロック

よく言われるやつなんですが、Oracleの読み取り一貫性がSQL Serverにはない。ということで、色々挙動が変わるのですが、最も影響がでたとこでいうと、SQL ServerのSELECTはデフォルトで、SELECT FOR UPDATEを実行したようなロックがかかってまう。 なので、SELECT文とDMLが同時に走るとDMLがだいたい待たされる。

これなにが困るってシステムの重い検索系の処理が走ると、更新系がタイムアウトでコケる。これだいぶ痛い。 ユーザーからするとせっかく更新内容をツラツラ入力したのに、タイムアウトエラーで、入力した内容が全部パーになってやり直しに。

で、対策としては、SELECT文にNOLOCK オプションをつけることで、ロックをかけないでSELECTすることができる。 でも、これって、ダーティリードになるから、思ってるのと違うねん。

READ_COMMITTED_SNAPSHOT オプション をつけることで、DB全体に読み取り一貫性を付与することができる。というのは喧伝されているので、ベンダーの担当者にそのことを依頼したのだが、

「そのオプションをつけると、他の処理にどのような影響が出るか責任がもてません」

という衝撃の回答。ERPのソフトメーカーでも、事例がないということで、見送りに。今でもこの回答おかしいと思ってるのだが、どーなのだろうか。

WIndows認証という名の闇

SQL Serverでは、Windows認証というのがあって、簡単に言うと、OSにログインできたら、DBにログインしたことにすればいーじゃないか。というもの。 で、監査とかでDBユーザーの一覧見せろとかたまに言われるから、使わないログインユーザーは無効にしときたいよね。ということで、Windows認証が有効になってたユーザーを無効にしたら、ERPのソフトウェアがバックエンドで使ってたみたいで、処理が落ちた。 死ね。

dboってなんやねん。

SQL ServerとOracleでは、オブジェクトの構成が異なる。 Oracleでは、

ユーザー（スキーマ） ． テーブル 名

でテーブルを呼ぶことができる（自分の所有するテーブルならテーブル名だけで呼べる）

SQL Serverでは、

データベース ．スキーマ ． テーブル名

という構成となっている。テーブルを、データベースとスキーマという２段階で分けることができるのだが、そこまで抽象化して分ける用途はあんまない。今回のERPソフトは、テーブル数は800以上あるのだが、データベースを業務ごとに大きく分けているだけで、スキーマで分けることはしていない。 ということで、FROM句を書く際に、いちいち、

SELECT * FROM database1.dbo.table1

のように、長ったらしい修飾子を毎回打つ必要がある。（use句を仕えばデータベース名はデフォルト値を指定できる） 毎回、”dbo”ってなんやねんって思いながら無駄な入力をするのがストレス。

開発ツール編（SQL DeveloperとSQL Server Management Studio）

それぞれ、DB用の開発ツールが公開されているが、これもOracleの方が使いやすい。

SQL Developer

SQL Server Management Studio（SSMS）

サクッとテーブルの中身が見たい

Oracle SQL Developerは、左のツリーから、テーブル名クリックすると、右側のエリアにタブが開いて、データタブを選択すると、テーブル内のデータがとりあえず表示される。 さらに、WHERE句の条件を入力するフィルターボックスがあり、そこに条件を打ってデータを検索できる。

SQL Server Management Studioでは、テーブル名を右クリックして、1000件選択する っていうメニューをクリックすると、SQL文が展開されて、下部にデータが表示される。 そして、展開されたSQL文にWHERE句を記述する必要がある。なにより、データの表示領域が狭い。

この地味だけど毎回やる作業ってのは、積み重なってかなりストレスになる。

SQLのエディター画面の表示形式

Oracle SQL Developerは、SQLエディターのエリアは一つのみ。 SQL Server Management Studioはタブ方式でいくらでも開ける。 この点は、SQL Serverの方が便利っぽく思えるが、タブがどんどん開くので、どこに何があるかわからなくなってしまう。Oracleは、１つのエリアに複数のSQLを書くような前提になっているので、わかりやすい。

で、この違いが効いてくるのが、複数のSQLを一つのタブに書いた際の挙動。

Management Studioでは、複数のSQLを書いた場合に、実行を押すと、書いてあるSQL全てが実行される（最初の図参照） 対するOracle SQL Developer は、;（セミコロン）で、区切られた１文のみを実行する。

これは、断然Oracleの方が使いやすい。Management StudioもSQLを選択することで、その文のみを実行できはするが、選択するのが面倒。

SQL エディター画面の表示形式２

Oracle SQL Developerでは、接続を切断しても、エディター画面は残ったまま。そこで、異なるインスタンスに接続し、残ってた旧接続のエディター上のSQLを実行すると当たり前のように接続エラーが発生する。

SQL Server Management Studio では、なんと同じことをすると、切断したはずの接続に対してSQLを発行してしまう。 この仕様のせいで、本番環境に繋いで、データ確認後、テスト環境に繋ぎ変えてDMLを実行するとアラ不思議、本番環境のデータが更新されてしまったではないか。

これは、オペミスの温床だからマジでやめてほしい。

ここでも読み取り一貫性が

Oracle SQL Developerだと、DML流してデータを更新してから、コミットするまでの間に、同一セッションでSELECT文を流すと変更の結果を確認することができる。 なので、コミット前にDML文が正しい結果かを確認し、それでOKならコミットして、変更を確定させることができる。

SQL Server Management Studio で同じことをすると、まず、BEGIN TRANSACTION 文で、トランザクションの宣言を記述しないといけない。そして、DML実行後のSELECT文はロック待ちになるので、延々待たされる。ので、毎回「あっ」てなって、SELECT文キャンセルして、nolockをつけて確認することになる。

読み取り一貫性考えた人ほんと天才。

文法

CREATE OR REPLACEがない

よく言われるやつ。

http://itmcreate.com/wp/archives/1373

SQL ServerでVIEWや、ストアドを作る場合は、Dropして、Createしなければならない。 で、Dropの文も、IF文で存在するかチェックして、Dropするような慣例句が使われる。 が、IF文でチェックするオブジェクト名のみ変換して、Drop文のオブジェクト名の変換を忘れて関係ないオブジェクトをDropしてしまうという不具合を発生させてしまうことに。

※2018/3/30 追記 SQL Server2016から、DROP IF EXISTS 構文が追加され、IF文とDrop文が分かれる課題は解消されているようです。 うちの環境は2014ですけども・・・。

列名を括弧で囲む、Nで囲む

Oracleでも、日本語列名とかアンチパターンをやっちゃう場合があるが、SQL SERVERでも同様。 ただ、SQL Serverの場合は、バージョンの下位互換のために、SQLで指定する列名の前にNをつけとけ。という謎の不文律が存在するみたい。面倒だから、自分で処理書く時はつけてない。今のとこ問題出てないけどいいのかな。 https://support.microsoft.com/ja-jp/help/239530/you-must-precede-all-unicode-strings-with-a-prefix-n-when-you-deal-with-unicode-string-constants-in-sql-server

その他

MSのマニュアルって見づらいし、グーグラビティが低いよね。特に、DBのバージョンを指定してるのに、ほしくないバージョンの結果が出てくるの止めて欲しい。

ブクマコメントで指摘がありましたが、確かにOracleもグーグラビティ低いかも。これは、慣れの問題か。

本の配送サービス比較 メルカリカウル用

メルカリカウルの配送方法ありすぎ

絶好調のメルカリの新サービス『メルカリカウル』を利用してみようと思い、読まなくなった書籍を売ってみようかとしてみたのだが、配送方法の選択肢の違いが全くわからず、出品できなかった。

で、まとめ記事は色々があるが、どこも説明が細かいんだけど、オレは一覧でざっと比較したいんだよ。ってタイプなので一覧にしてみた。

なお、本１冊を送るのを想定しているので、以下の配送方法は調べてねえ。

普通郵便、クロネコヤマト、らくらくメルカリ便（大型）

また、はこBOONはサービス停止のお知らせが出たので調べてません。

配送の比較表

どーん

Googleスプレッドシートにも作ったので、見づらい方はそちらをどうぞ

メルカリカウル配送方法比較 - Google スプレッドシート

なお、郵便受けに送るサービスでも、郵便受けに入らなかった場合は、対面で渡してくれるそうです。そんなもんなんですね。

また、スマートレターについては、メルカリで配送方法選べないけど、おすすめしてる記事があったので、載せてみた。 メルカリで選ぶ時は、ゆうメールとほぼ一緒だから、ゆうメールか、普通郵便選べばいいのではないだろうか。

厚さと重さってどんなもんなの

でもって調べてみて思ったのは、大きさは、スマートレター以外はA4サイズOKなので、本に関してはほとんど気にしなくていい。 ただし、問題は、厚さと重さ。 これが、わからん。

なので、身近にあった書籍のページ数と厚さと重さをだっと測って、それぞれが配送するのに１番安いサービスと２番目に安いサービスを調べてみたよ。

値段的には、クリックポスト圧勝なのだが、送り状ラベルを自分で印刷する必要がある。つまり、プリンターが必要。これがつらい。 我が家にも、プリンターがないが、同じような人は多いんではないだろうか。

そうなると２番目の選択肢を考える必要になり、条件によっては、スマートレター、らくらくメルカリ便（ネコポス）、ゆうぱけっとｏｒゆうメールということになる。

なお、厚さに関しては、上記の大型本の平均を取ってみると、159ページで1cm という結果になった。ご参考までに。

まとめ

• 本の厚さが３cmを超える → らくらくメルカリ便（小型）￥380
• 本の厚さが３cm以内
  • プリンタ持ってる → クリックポスト￥164
  • プリンタ持ってない
    • 厚さ２cm 以内 かつ A5サイズ（25✕17） → スマートレター ￥180
    • 厚さ2.5cm 以内 → らくらくメルカリ便（ネコポス）￥195
    • 厚さ3cm 以内 → ゆうぱけっとorゆうメール ￥350

200円とか多少損してもいいから、トータルの作業も含めて一番ラクなのは、ゆうメールだろうか。 350円分の切手貼って、封筒に「ゆうメール」って書いて、ポストに投函するだけなんで。

ここまで調べるのに４時間かかったよ・・・。

最近流行りのRPAとは

今年で休刊が決まった日経ストラテジー。確かに最近惰性で読んでたが、気になったのがあった。

2017年5月号集が組まれたRPA（ロボティック・プロセス・オートメーション）。

wikiによると

ロボティック・プロセス・オートメーション（Robotic Process Automation, RPA）とは、認知技術（ルールエンジン・機械学習・人工知能等）を活用した、主にホワイトカラー業務の効率化・自動化の取組みである。人間の補完として業務を遂行できることから、仮想知的労働者（Digital Labor）とも言われている。 ロボティック・プロセス・オートメーション - Wikipedia

なんか、最近流行りのAI、ディープラーニング、IoT、ロボットなどを想像させるその用語から、また新しいバズワードかと思ったが、記事を読んでみると、

Oracle Functional Testing（OFT) に毛が生えた感じやん。

というのが第一印象。

OFTを知らない人向けに説明すると、Seleniumに毛が生えた感じといえばニュアンスが伝わるだろうか。

ようは、GUIの自動テストツール。

当ブログでは、OFTの記事をちょこちょこ書いているのですが、もともとはE2Eの自動テストのためのツールって、テストだけだと勿体無いから、テストツールを使って業務を自動化するという使い方はよくある話。

ryoben.hateblo.jp

じゃぁ、何が違うの。

この記事で紹介されているRPAは少し進化している。

• Web以外のアプリケーション全てに対して動作を自動化できる
• 各アプリケーションの操作をノンプログラミングで記述できる
• 各アプリケーションをシームレスに繋いで、処理を条件分岐できる

例えばCRMで、新規登録された顧客マスタを、販売管理システムに手動で連携するとかのケースではないだろうか。（ASPだとAPIとかないし）

① WebのCRMシステムに新規登録された顧客一覧を表示し、CSVにダウンロード
② そのCSVをEXCELのマクロで加工して保存
③ CSVを、クラサバの販売管理システムにインポート

こういうケースだと、Webのテストツールで自動化できるのは、①だが、RPAだと、OS上の操作全てをエミュレートできるので、①〜③全部を自動化できる。

どんなツールなのか

紹介されていたのは、以下のツールたち。

• Automation Anywhere Enterprise 米オートメーション・エニウェア （日本では、日立ソリューションズが代理店） www.automationanywhere.com

• BizRobo! RPAテクノロジーズ bizrobo.com

• UiPath Studio/Robots/Orchestrator 米ユー・アイバス （無料で使えるのコミュニティエディションがある。商用利用は条件あり） www.uipath.com

• ナイス・ロボティックオートメーション アイティフォー www.itfor.co.jp

• NTTアドバンステクノロジ WinActor www.nttdata.com

なぜ急に流行りだしたのか

導入事例として紹介されているユーザーは、三菱東京UFJ、オリックスグループ、日本生命保険、リクルートコミュニケーションズなどの大手も使っている。 ただ、使い方としては、バックオフィスの人員削減および、属人化排除のためと思われる泥臭い作業ばかりだ。

やはり、１企業の中で見た場合、どうしてもシステム化するより人で対応した方が費用対効果が高い領域というのは存在する。 契約関係とか、人事総務の手続き関係とか、細かい条件によって微妙に作業が異なったりで人の判断が必要な部分。または、ルールや手順がしょっちゅう変わって、システム化に向かない部分。
そういった部分について、ここ最近の自動化の技術が成熟してきて、RPAを導入することで費用対効果が出るようになったのだろうと考察する。

もう一点あるとすれば、クラウド化の影響。ここでいうクラウドは、SaaS。
勤怠、経費精算、人事システム、CRMとかのバックオフィス系のシステムはSaaSを利用するのは当たり前になってるが、ここにきて販売管理やらの基幹系までSaaSで置き換えるケースは増えてる。
そうなると、システムが完全に分離されちゃって、EAIなんかを使用して裏側でデータ連携はできない。
APIがあれば、まだ可能性もあるけど、開発にお金かかるし、とりあえず人手で対応。って負債ができちゃうのでは。

メンテが大変そう

システムのE2Eの自動テストって、メンテが大変じゃないですか。
ちょっと画面のレイアウト変わっただけでも、全部落ちるし。
記事の中でも紹介されていたが、それはRPAも同じで、メンテしやすい構成にすることが大事と書かれていた。
また、複数のアプリをシームレスにつなぐ分、処理の単位をどう区切るかも大事だそうだ。

確かにアプリケーションごとに処理を切り出すのが簡単そうだが、
『CRMに登録された顧客の業種によって、販売管理のマスタに登録する手順が異なる』とかいう業務の場合、CRM上の顧客の属性ごとに、販売管理側も含めたシナリオを作成するとかなると、大量のシナリオを作らねばならんことになり、メンテも死ねるので、やりたくないよねぇ。

ということで、コツはありそうである。

流行るの？

流行るか、流行らんかといえば、大企業では営業事務とか、企画事務とか、○○事務って名のつく派遣の社員の人とかいるじゃないですか。ああいうとこの人数を減らすのには、効きそうですよね。
ただ、現状初期費用が数百万円なので、大企業しか導入できん。
RPAの人気が上がれば、中小企業でも導入できるパッケージが提供されるだろうが。

お金かけたくないなら、RPAなんて言葉ができる前から存在する UWSC とかで効果あるか試してみればどうか。

日経情報ストラテジー 2017年 05 月号 [雑誌]