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

そらとぶへび

仕事・プライベートを通しての気づき、JavaやPHP、データベースやサーバの話などこつこつと書いていきます

ALTER TABLEによるセッションのロック

MYSQLトランザクション中のテーブルに対し、ALTER TABLEを実行したらどうなるのか?
試してみたところ、トランザクションを終了するまで、他のセッションをロックしてしまう。

検証パターン

①コンソールからMysqlへ接続してトランザクション開始

start transaction;
select * from test;

②別コンソールを立ち上げて、ALTER TABLEなどを実行。

ALTER TABLE test add column b char(10) default 'b';

③さらに別コンソールを立ち上げて、SELECTを実行。

select * from test;


①でトランザクションを終了するまで、②、③の結果は返らない。

トランザクションの分離レベルを変えてみる

セッションをダーティリードに変更したら、コミット前の変更が別トランザクションから参照できるので、回避できるのでは?と思ったが、試してみた結果は同じ、結果は返らない。
セッション単位でロックしているだろうか?

SET SESSION TRANSACTION ISOLATION LEVEL read uncommitted;
select @@tx_isolation;
+------------------+
| @@tx_isolation   |
+------------------+
| READ-UNCOMMITTED |
+------------------+
1 row in set (0.00 sec)
結論

バッチ処理等の長いトランザクションが実行されている中でALTERコマンドを実行しない。
SELECT文であっても、ロックがかかるので、不必要にトランザクション処理しない。

TABLE ACCESS FULLしているSQLを探す

Oracleでパフォーマンス低下したり処理遅延が発生するようになった際の原因調査手段として、
V$SESSION_LONGOPSから手掛かりを探せる可能性がある。

V$SESSION_LONGOPS

V$SESSION_LONGOPSは、実行に6秒(絶対時間)より長くかかる様々な操作の状態を示します。現在これらの操作には、多くのバックアップおよびリカバリ機能、統計収集、問合せ実行、およびOracleリリースごとに追加される多くの操作が含まれます。

ここでは、TABLE ACCESS FULLしているSQLを探すケースを記載する。


■対象テーブルとSQL_IDの抽出

select count(sid) as cnt, 
  sql_id, 
  target, 
  sql_plan_options  
from v$session_longops t  
where t.sql_plan_options = 'FULL' 
group by sql_id ,target,sql_plan_options  
order by cnt desc;


実行結果
CNT SQL_ID TARGET SQL_PLAN_OPTIONS
170 c1y7mg1xfgznb USER.TABLE_NAME1 FULL
20 bd22x5v9dx79k USER.TABLE_NAME1 FULL


対象テーブルが特定できた。SQL_IDから、対象のSQL文をv$sqltext から抽出する。


SQL文の抽出

select sql_text 
from v$sqltext 
where sql_id = 'c1y7mg1xfgznb' 
order by piece;



対象のSQLも特定できた。実行計画を確認すれば、TABLE ACCESS FULLしていることがわかるはず。
今回は最も件数の多いSQLを確認しているが、処理の長いSQLを探すためにelapsed_secondsで絞込むのもありかと思われる。

あとはヒント文で解決するなり、インデックスを見直すなり、状況に合わせて対処していく。

ELB配下のEC2にBasic認証とヘルスチェックを設定する。

ELB配下のEC2とするためヘルスチェックを設定したい。しかしBasic認証をかけておきたい。
という場合の設定。
備忘のためメモしておきます。


Basic認証配下にヘルスチェック先があると、401エラーになってしまい正常なヘルスチェックができない。
その場合は、以下のようにApacheのConfを設定し、ヘルスチェック先のみベーシック認証対象から除外します。

ベーシック認証を設定。ただしヘルスチェック先を除外する。
# いずれかの条件を満たせばアクセス可
Satisfy Any

# ベーシック認証によりアクセスを許可
AuthUserfile /home/hogehoge/application/public/.htpasswd
AuthGroupfile /dev/null
AuthName "Please enter your ID and password"
AuthType Basic
require valid-user

# リクエストURLがヘルスチェック先の場合は、アクセスを許可
setEnvIf Request_URI "/health_check/index.php" healthcheck
Order Deny,Allow
Deny from all
Allow from env=healthcheck
ヘルスチェックログの出力先を分ける

ヘルスチェックログとアプリログを混在しないように、以下の設定で出力先を分けます。

  DocumentRoot /home/hogehoge/application/public
  SetEnvIf User-Agent "ELB-HealthChecker.*" nolog
  SetEnvIf User-Agent "ELB-HealthChecker.*" elb
  ErrorLog /home/hogehoge/application/logs/error_log
  CustomLog /home/hogehoge/application/logs/access_log combined env=!nolog
  CustomLog /home/hogehoge/application/logs/health_check_access_log combined env=elb

ちなみに、ロードバランサー作成後にヘルスチェック先変更する場合は、ターゲットグループの方のタブから行うらしい。。

ChromeやSafariで現在地情報が取得できない件

GPS関連(Geolocation API )を調べていて気が付いたのですが、
ChromeSafariの仕様変更により、http接続の場合、現在地情報の取得ができなくなったため、
スマートフォン関連での現在地検索が利用できなくなっていました。

 ・Google Chrome(PC用を含む)  2016年4月から 
 ・iOSiPhoneiPadiPod touch) 2016年9月から

今後も、http接続での現在地取得を禁止するブラウザが増えていく傾向にあるようです。

サイト全体がhttpsに対応していればリダイレクトさせる、
そうでない場合は、GPS取得時のみだけでも、httpsに対応したページを作成する
などの対応が必要になります。


@IT ・Webブラウザで現在地情報を正しく取得できない場合の原因と対策
Tech TIPS:Webブラウザで現在地情報を正しく取得できない場合の原因と対策 - @IT

CSV(Creating Shared Value/共有価値創造)とは何ぞや

もともと経営論云々というのは疎くて、あまり興味を持っていなかったけれど、
最近、CSV経営という概念を知って共感・感銘を受けたので、簡単にまとめてみます。
f:id:lue4881:20161022105003j:plain

CSV(Creating Shared Value/共有価値創造)とは

マイケル・ポーター教授の提唱するCSV(Creating Shared Value/共有価値創造)とは、単に「経済価値」のみを追求するのではなく、「社会価値」を生み出していこうとするソーシャルビジネス的な視点が含まれる概念となります。

ここでいう「社会的価値」とは、事業を通して社会問題、社会課題を解決することで、企業としての存在価値・競争力を高めていこうとする経営戦略です。

従来のCSR(Corporate Social Responsibility/企業の社会的責任)がコンプライアンスや環境マネジメント、社会貢献活動など本業以外での活動を指していたことに対し、CSVでは本業、つまり事業そのものが社会的貢献につながることを目指しています。

どんな企業がCSVに取り組んでいるか

www.nestle.co.jp

例としてネスレはCreating Shared Value Teamを社内につくり、世界各地でCSVプロジェクトをつくり、積極的な取り組みが行われています。


www.jri.co.jp

上記の記事では、伊藤園ツムラ、エーピーカンパニーの3社を事例に挙げています。


いずれも、ただ調達価格だけで取引先を選ぶのではなく、お互いにパートナーとしてビジネスを育てていくというイメージです。
資源調達先の支援を通じて、品質向上や長期的なエンゲージメント効果があるのだそうです。

まとめ

企業が一時的な経済利益の最大化を主目的として活動した結果引き起こされる社会問題・環境問題が数えきれないほどにあります。
そのなかで、CSVの理念に基づいて事業に取り組む企業が増えていくことは、望ましいものだと感じています。

スパムメール・偽装メールの確認方法

まず初めに、メールヘッダの読み方について、説明します。

メールクライアントソフトによって、表示のさせ方は異なりますが、
ヘッダ情報としては、以下の構造になっています。

===============================================================
[エンベローブ]
 MAIL FROM ・・・送信元
 RCPT TO  ・・・送信先
 DATA

[ヘッダ]
 Retrurn-Path ・・・送信元アドレス
 Delivered-To ・・・宛先アドレス
 Recevived   ・・・メールを送信したメールサーバの情報
 From     ・・・送信元アドレス(メールの作成者が入力したもの)
 To      ・・・宛先アドレス(メールの作成者が入力したもの)
 Subject    ・・・件名

[メール本文]
 ・・・
 ・・・
 ・・・

===============================================================

エンベローブはメールサーバが送信に使う情報、
ヘッダは送信者や受信者の便宜のために準備された情報になります。

基本的に両者は同じ情報ですが、メールサーバはエンベローブしか見ていないので、
エンベローブとヘッダに差異があっても、送信自体には問題がありません。
つまり、送信元でヘッダ情報はいくらでも偽装が可能になっています。

ただし、Recevivedフィールドは、経由したメールサーバが付加した情報なので、
比較的改ざんの難しい場所
になります。
なので、ほかのフィールドとRecevivedフィールドの整合性が取れないことを頼りに、
偽装メールを判別することができます。

Recevivedフィールドは以下のような記述となっています。

Recevived:from 送信元 MTA by 送信元 MTA

この送信元と、送信先がちぐはぐになっていれば、偽装された可能性は高いと判断することができます。

DNSに関するあれこれ

f:id:lue4881:20160926231339j:plain

ここでは、DNSに関する基本とDNSキャッシュポイズニングに対する対策を紹介します。

DNSサーバの基本

DNSサーバはコンテンツサーバとキャッシュサーバに分類できます。

コンテンツサーバ・・・オリジナルのDNS情報を補完するサーバ
キャッシュサーバ・・・コンテンツサーバから得られたDNS情報を一時的に保管するサーバ

名前解決の問い合わせがあった場合、以下のような流れで、処理を行います。

  1. クライアントは通常、自組織のキャッシュサーバに再帰的な問い合わせを行う。
  2. キャッシュサーバは問い合わせを受けて、コンテンツサーバに問い合わせを行う。
  3. キャッシュサーバはコンテンツサーバから得られたDNS情報をクライアントに返答する。
  4. それと同時に、DNS情報のコピーを一定期間保存する。

問題点として、コンテンツサーバからの回答は、とくに認証を必要としないことです。つまり本物の回答の前に、偽の回答を返答してしまえば、うそのDNS情報をキャッシュサーバに記憶させることができてしまいます。これを、DNSキャッシュポイズニングといいます。

DNS情報を汚染されたキャッシュサーバに問い合わせをすると、攻撃者が設置した悪意のあるサーバに通信を誘導されます。また、大きなDNS情報を記憶させたうえで、キャッシュサーバに送信元を詐称した問い合わせを行うことで、DNSリフレクション(DNS amp攻撃)が行われます。

DNSサーバを運用する際には、自社が最終ターゲットでないとしても、踏み台にならないように対策が必要になってきます。

続きを読む