読者です 読者をやめる 読者になる 読者になる

セカイモンの裏側

★毎週木曜日更新★ 海外ショッピングサイト『セカイモン』のブログです。私たちスタッフの仕事風景や日々の出来事など、     “セカイモンの舞台裏”とも言える日常を綴っていきます。

ORACLEのゾンビテーブル

オラクルでは大文字小文字を区別してテーブルも作れるらしい。

でも区別しなくてもいい設定もできるらしい。

どっちかにして欲しい

今回間違えて小文字で作成して、大文字でも作成して、削除したのにまだ残ってしまうっていうおかしな現象に突入しました。

 

selectは受け付けない 表がないから。。。

dropは受け付けない 表があるから。。。

うわぁー。

 

hito4-t.hatenablog.com

nmtuiって面倒くさい

楽にするためのCUIなのにCentOS7から推奨のnmtuiを使用して1時間ぐらいつまったのでメモ

>ntmui

f:id:sekaimon-staff:20170427133847j:plain

接続の編集

f:id:sekaimon-staff:20170427133929j:plain

編集、ここも追加がトップにくるのでつい追加してしまいそうになる。

f:id:sekaimon-staff:20170427134047j:plain

はまった箇所、サブネットマスクを入れないといけない。

エラーも出ないのでなかなか気づかない所

あとの設定はこんなものでいいかな。。

OKでエンタ

f:id:sekaimon-staff:20170427133847j:plain

またここで接続をアクティベートしないと動かない

OKでエンタでさらに

systemctl restart NetworkManager

でやっと反映される。

簡単になったのか難しくなったのか。。

 しかもteratermとかのターミナルで入れるけども、途中でサイズを変更するとCUIの画面がくずれるからはじめからやり直しという無残な結果に

MySQL 他のテーブルを参照してUPDATEとカラムの追加

他のテーブルを参照してUPDATEする場合

update h_mypage_history, tmp_settlement
set h_mypage_history.shipping_fee_settlement = tmp_settlement.current_amount
where h_mypage_history.BUNDLING_ID = tmp_settlement.settlement_key;

このSQLupdate h_mypage_history tmp_settlementのようにコンマが抜けてたから、

エラーが出て若干つまった

 

10:52:29 update `h_mypage_history` `tmp_settlement` set `h_mypage_history.shipping_fee_settlement` = `tmp_settlement.current_amount` where `h_mypage_history.BUNDLING_ID` = `tmp_settlement.settlement_key` Error Code: 1054. Unknown column 'h_mypage_history.BUNDLING_ID' in 'where clause' 0.015 sec

こういうエラーが出てきたけども、単純にコンマが足りないミスだった。

 

bashalog.c-brains.jp

 

alter add が遅い?? 一瞬かと思ったけどレコード分待たないといけないみたい。。

結局10分ぐらいかかった。残念な話。

試しにDROP COLUMNをしても一瞬とかではなく10分ぐらいかかる。

レコード多いテーブルにカラムを追加、削除する時はメンテナンスが必要!?

となると運用がさらに難しくなりそう。。。

key_buffer_size を変更すると早くなるみたい、やっぱりMySQLはデフォルトでは運用が難しくカスタマイズがそこそこ必要っぽい。

やっぱり俺はPostgresが好きですな。

d.hatena.ne.jp

よく100万件~1000万件ぐらいの場合は件数としてはたいした事がなくて、インデックスを貼れば問題ないみたいな話になるけど、100万件以上はパフォーマンスに影響すると思う。特に主要テーブルとかになるとカラム数とかも増えるんで

件数は100万件を超えない、カラム数は10カラムを超えないを心がけたいところです。

google analytics(GA)のビューのフィルタはビュー毎に独立していない

google analyticsのフィルタ設定で次のような問題起こってしまった。


1.google analyticsの管理>コピー対象のビューを選択>ビュー設定>ビューをコピー
2.コピー元のビューにフィルタ設定がされていました(今回の場合は社内からのIPを制限するフィルタ)
3.コピーして新規で作成したビューは「社内からのIPのみを許可する」フィルタを設定
4.コピー元のフィルタ設定まで「社内からのIPのみを許可する」に変わってしまった。

 

■過ち
コピー元ビューのもともと設定されていた「社内からのIPを制限する」フィルタを編集してしまった。正しいやりかたは新規でフィルタを作成する。

■結論
フィルタは各ビュー間で共通の設定を持っていてビュー毎に独立していない。

手習いHTML5 (3)

今回は、実際にブラウザに表示される領域での基本的なタグをいくつか覚え書きする。

■<HEADER>
<HEAD>とよく似た名称であるが、表示上のヘッダー領域は<HEADER>タグ内に収納される。

<HEAD>はページ本体の基本情報を収納しているため、<HEAD>タグもヘッダーとして表現されることが多く、非常にややこしい。

<HEADER>タグに収納された情報は、表示されるブラウザの上部に配置され、スクロールされても上部は表示を固定されていることが多い。
トップページや主要ページへのリンクが表示される。

■<FOOTER>
<FOOTER>は<HEADER>とは対照的に、表示されたブラウザの下部に配置される。
<HEADER>とは異なり、最下部までスクロールされて初めて確認されるものが多く、商標表示や各種リンクがコンパクトにまとめられていることが多い。


これら2つのタグは、</HEADER>あるいは</FOOTER>によって閉じることで機能する。
なお、それぞれのタグ内部に<HEADER><FOOTER>の構造を挿入することはできないようだ。

セカイモンLinux テクニック

その1 ディレクトサイズを知りたいコマンド

フォルダ・ディレクトリのサイズを一覧で出したい時のコマンド

意外とぐぐっても出てこないんで記載しておきます。

du -sh

例:

du -sh /var/www/forum/*

14M /var/www/forum/app
4.0K /var/www/forum/artisan
16K /var/www/forum/bootstrap
4.0K /var/www/forum/Capfile
4.0K /var/www/forum/composer.json
120K /var/www/forum/composer.lock
1.8M /var/www/forum/composer.phar
36K /var/www/forum/config
816K /var/www/forum/lib
4.0K /var/www/forum/phpunit.xml
51M /var/www/forum/public
8.0K /var/www/forum/README.md
4.0K /var/www/forum/server.php
59M /var/www/forum/vendor

その2 ログを見るコマンド

ログをLinux上で見るときはおなじみのtail コマンド等があると思いますが、それぞれメリットデメリットがあります。

そこで一番個人的によく使うコマンドはlessです。なぜかという理由を記載しながら書いていきます。

・tailコマンド

デメリット

tailコマンドは上ボタンでそれ以上見れない

引数がややこしい

あとtailfに比べると遅い

メリット

行数を指定できる

リアルタイムで監視できる

tailfコマンド

デメリット

上ボタンでそれ以上見れない

メリット

tailに比べると早い

なのでリアルタイム監視をしたい時はtailfコマンドをよく使っています。

・viコマンド

デメリット

遅い

メリット

編集できる

大量のログを見るときはviだととても遅いので見れない場合が過去にありました。

編集できてもログファイルなのであんまりいみないですね。

・viewコマンド

デメリット

編集できない、なので大事なファイルをいじるときはメリットとも言えるかも

メリット

特にない?

・catコマンド

大量ログのファイルをcatすると考えたら恐ろしくてできない。

・lessコマンド

デメリット

編集できない

メリット

高速

自由にスクロールできる

なのでlessコマンドでいいんじゃないでしょうか?

www.softel.co.jp

その3 文字化けに困ったら

viによるShift-JISのファイル開き方

OracleSJISメッセージをだし、文字化けをするのでsjisの開き方とか少々便利かと思い、念のため記載。

vi
ファイルを開く
# vi logs/test.log

その後、基本viでは直接編集はできないコマンドモードと呼ばれる状態でファイルを開いており、【:】を押すとコマンド受付になる。

:e ++enc=sjis

:eはファイルをオープンする命令で++encで文字コードを指定できる。

ORACLE SQL テクニック

実行計画のススメ

まず、大前提としてSQLを修正する際には書いたSQLを実行計画で確認することをお勧めする。

実際のSQLを投げるのと違い、直ぐに応答があるため動作チェックの意味でも投げることをお勧めする。

自分の書いたSQLがどのように動くかも含め確認するとよい。

また、実行計画ボタンの隣に自動トレースボタンがあるが、こちらは実行計画だけではなく

  • SQL再帰回数
  • 読み込みブロック数
  • ソート回数
  • 処理行数

等の内容も加えて表示される。(現状、権限がないので実行できなかった)

 

 

修正その1:EXISTSと相関サブクエリ

 

上記の画像のように本クエリとサブクエリ間で互いに参照をしているクエリを相関サブクエリと呼びます。

この相関サブクエリでは互いにデータを参照しあう関係上、データのアクセス数が膨大になりやすく、SQLの処理時間が

増大しやすくなります。

対応法は上記のように内部結合処理への書き換えを推奨します。

引用:EXISTSが速いという誤解

kkoudev.github.io

修正その2:ウィンドウ関数

SQLにて集合関数は重い処理にあたる。理由はその性質上、データの集計を行うため、基本全てのデータにアクセスする必要があるためである。

したがって、よくある履歴データ等の最新データを拾うために結合×集合関数(Max)等の処理を行う場合には

 駆動テーブルのデータ数 × 結合テーブル(Max対象テーブル)の全データ数

の処理が行われ、処理が重くなりがちである。

上記データに関するSQLの差分はSubversionのrevision:11372を参照のこと。

修正その3:IN句の失敗例

詳細は記載しないが、PHP等のプログラム側で条件項目を保持して、SQLを組み立てる場合がよくある。

その時に条件項目が膨れ上がり1000件を超えると下記のようになる。

また、上記エラーの件を除いても下記理由から避け、プレースホルダに変更すべきである。

  • 単純にIN句はパフォーマンスが低い
  • PHP側で展開するとSQLの文が異なり、キャッシュにヒットしない
  • SQLインジェクション対策 等

番外:複合インデックスについて

複合インデックスは複数のカラムを指定し、単一のインデックスよりより詳細な絞込み対象を作ることで高速化を行うインデックスとなる。

複合インデックスのカラム指定は単純に記載しがちだが、記載順序が重要となる。下記2項を特に注意すること。

  • 複合インデックスは先頭のカラム要素のみ使用といった具合に、部分的に使用可能なため頻度が高いものは先に記載するとよい
  • 逆に先頭のカラムを使用しない場合は、その後のカラムがインデックスにあっても使用されることがないため注意する
  • 範囲検索を行うと後続のインデックスは使用されなくなるため注意(Date型等は特に後ろに回した方がよい)

詳細なデータ検索範囲は下記ページに例がある

http://itdoc.hitachi.co.jp/manuals/3000/30003F5500/EEXD0043.HTM