13 posts categorized "データベース"

May 15, 2011

MySQLアクセスはGUI派? それともCUI派?

Twitter内で、MySQL管理はGUIとCUIのどちらがいいのか、という論争がありました。私個人としては、断然GUI派です。CUIも一応使えますが、GUIが使える環境であれば迷わずGUIを使います。

データベースって、例えば細かい権限設定などをCUIでやろうとすると、見にくいのでどうしてもケアレスミスが発生しがちです。GUIであれば直感的な操作で対応できる場合が多いので、ケアレスミスが少なくなります。

・・・という表向きの理由がありますが、実は「privileges」という単語をどうしても覚えられなくてCUIだとつらいという状況が続いていました。MySQLのCUIって全般的に覚えにくい気がします。さすがに5年目くらいには慣れてきて今では大丈夫になりましたが。


[関連記事]
急いでいる人のためのMySQLのユーザ権限付与講座

| | Comments (0) | TrackBack (0)

November 02, 2010

MySQLのSQLクエリーだけで棒グラフを表示する方法

MySQLの出力結果を棒グラフで表示できたらいいなぁと思っていろいろ実験していたらうまくいってしまったのでご紹介してみます。

【普通の場合】
普通は以下のようになりますよね。出力結果だけ見てもどうもよくわかりません。

■SQL文

mysql> select date_format(regdate, "%Y/%m/%d %H") date, count(*) count from usert group by date order by date asc;

■出力結果

+---------------+-------+
| date     | count |
+---------------+-------+
| 2010/11/01 00 |  405 |
| 2010/11/01 01 |  276 |
| 2010/11/01 02 |  188 |
| 2010/11/01 03 |  148 |
| 2010/11/01 04 |  96 |
| 2010/11/01 05 |  63 |
| 2010/11/01 06 |  85 |
| 2010/11/01 07 |  142 |
| 2010/11/01 08 |  164 |
| 2010/11/01 09 |  137 |
| 2010/11/01 10 |  177 |
| 2010/11/01 11 |  177 |
| 2010/11/01 12 |  248 |
| 2010/11/01 13 |  178 |
| 2010/11/01 14 |  148 |
| 2010/11/01 15 |  158 |
| 2010/11/01 16 |  195 |
| 2010/11/01 17 |  213 |
| 2010/11/01 18 |  243 |
| 2010/11/01 19 |  236 |
| 2010/11/01 20 |  274 |
| 2010/11/01 21 |  310 |
| 2010/11/01 22 |  309 |
| 2010/11/01 23 |  280 |
+---------------+-------+


【棒グラフの場合】
そして今度は出力結果を棒グラフにした場合の例になります。ものすごくわかりやすくなりました。

■SQL文

mysql> select date_format(regdate, "%Y/%m/%d %H") date, REPEAT("#", count(*)/10) graph from usert group by date order by date asc;

■出力結果

+---------------+-------------------------------------------+
| date     | graph                   |
+---------------+-------------------------------------------+
| 2010/11/01 00 | ######################################### |
| 2010/11/01 01 | ############################       |
| 2010/11/01 02 | ###################            |
| 2010/11/01 03 | ###############              |
| 2010/11/01 04 | ##########                |
| 2010/11/01 05 | ######                  |
| 2010/11/01 06 | #########                 |
| 2010/11/01 07 | ##############              |
| 2010/11/01 08 | ################             |
| 2010/11/01 09 | ##############              |
| 2010/11/01 10 | ##################            |
| 2010/11/01 11 | ##################            |
| 2010/11/01 12 | #########################         |
| 2010/11/01 13 | ##################            |
| 2010/11/01 14 | ###############              |
| 2010/11/01 15 | ################             |
| 2010/11/01 16 | ####################           |
| 2010/11/01 17 | #####################           |
| 2010/11/01 18 | ########################         |
| 2010/11/01 19 | ########################         |
| 2010/11/01 20 | ###########################        |
| 2010/11/01 21 | ###############################      |
| 2010/11/01 22 | ###############################      |
| 2010/11/01 23 | ############################       |
+---------------+-------------------------------------------+

| | Comments (0) | TrackBack (0)

October 12, 2010

急いでいる人のためのMySQLのユーザ権限付与講座

MySQLでは細かいレベルの権限付与が可能ですが、大抵の場合そこまで細かいレベルの権限付与は必要ないですよね? マニュアルを読まないか、もしくはちょっとしたメモ書きを見る程度でおおよそ使い方が理解できるくらいならいいのに、といつも思います。

そこで今回は、MySQLのユーザ権限付与の中でも、とりわけよく行われる手順だけを簡単にまとめてみました。

【まず知っておいたほうが良いこと】
ユーザはmysqlデータベース内のuserテーブルに作られます。

次に例えば以下のユーザの情報を見てみると「_priv」系のカラム値が全部「Y」であることがわかります。この場合はグローバルレベル権限として全部「Y」なので、全てのテーブルに対して接続が可能となります。

mysql> select * from user where User='adminuser' \G
 
*************************** 1. row ***************************
                 Host: %
                 User: adminuser
             Password: 136b4c537575b6f1
          Select_priv: Y      ←
          Insert_priv: Y      ←
          Update_priv: Y      ←
 
~~~中略~~~
 
  Create_routine_priv: Y      ←
   Alter_routine_priv: Y      ←
     Create_user_priv: Y      ←
             ssl_type:
           ssl_cipher:
          x509_issuer:
         x509_subject:
        max_questions: 0
          max_updates: 0
      max_connections: 0
 max_user_connections: 0
1 row in set (0.00 sec)

一方、以下のユーザの情報を見てみると「_priv」系のカラム値が全部「N」であることがわかります。

mysql> select * from user where User='testuser' \G
  *************************** 1. row ***************************
                 Host: localhost
                 User: testuser
             Password: 136b4c537575b6f1
          Select_priv: N      ←
          Insert_priv: N      ←
          Update_priv: N      ←
 
~~~中略~~~
 
  Create_routine_priv: N      ←
   Alter_routine_priv: N      ←
     Create_user_priv: N      ←
             ssl_type:
           ssl_cipher:
          x509_issuer:
         x509_subject:
        max_questions: 0
          max_updates: 0
      max_connections: 0
 max_user_connections: 0
1 row in set (0.00 sec)

この場合は、別途ユーザが接続するデータベースを「db」テーブルに設定します。

mysql> select * from db where User='testuser' \G
 
*************************** 1. row ***************************
                 Host: localhost
                   Db: testdatabase
                 User: testuser
          Select_priv: Y
          Insert_priv: Y
          Update_priv: Y
 
~~~中略~~~
 
  Create_routine_priv: Y
   Alter_routine_priv: Y
         Execute_priv: Y
1 row in set (0.00 sec)

普段意識すべきはこのあたりまでだと思いますが、さらに細かい設定を検討する場合は以下もご参照下さい。

※参照:mysqlデータベース内のテーブル一覧

データベース名 説明
user グローバルレベルの権限とパスワードを管理するテーブル
db データベースレベルの権限を管理するテーブル
host(今回は考えない) dbテーブルにホスト名が指定されていない場合に適用される権限を管理するためのテーブル
tables_priv(今回は考えない) テーブルレベルの権限を管理するテーブル。テーブル内のすべてのフィールドに適用される権限について格納。
columns_priv(今回は考えない) フィールドレベルの権限を管理するテーブル。テーブル内の一つのフィールドに適用される権限について格納。

これをふまえて。


【1.管理者用ユーザを作りたい】
いわゆる何でもできる管理者用ユーザは以下の要領で作ります。

GRANT ALL ON *.* TO adminuser@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;

※MySQLにはGRANT権限というものがあります。GRANT権限とは、他のユーザに対して権限を付与することができる権限のことです。当然のことながらGRANT権限は通常管理者用ユーザにか付与しません。

IP制限をかける場合は以下の要領です。

GRANT ALL ON *.* TO adminuser@'172.16.0.0/255.255.255.0' IDENTIFIED BY 'password' WITH GRANT OPTION;


【2.一般ユーザを作りたい】
全てのデータベースにアクセスできる一般ユーザは以下の要領で作ります(WITH GRANT OPTIONがないのに注目)。ただし全てのデータベースにアクセスできる一般ユーザをGRANT ALL ON *.*で作ると、SUPER権限がつくのでinit_connectが無視されるなどの副作用があるそうです。(sh2さんご指摘ありがとうございました)

GRANT ALL ON *.* TO testuser@'%' IDENTIFIED BY 'password';

特定のデータベースにアクセスできる一般ユーザは以下の要領で作ります。

GRANT ALL ON testdatabase.* TO testuser@'%' IDENTIFIED BY 'password';

SELECT,INSERT,UPDATE,DELETEしかできない一般ユーザは以下の要領で作ります。

GRANT SELECT,INSERT,UPDATE,DELETE ON testdatabase.* TO testuser@'%' IDENTIFIED BY 'password';


【3.レプリケーション用ユーザを作りたい】
MySQLの大きな特徴であるレプリケーションを行う場合、MASTER DBに以下の要領でユーザを作ります。

GRANT REPLICATION SLAVE ON testdatabase.* TO repl@'172.16.0.0/255.255.255.0' IDENTIFIED BY 'password';

【最後に】
柔軟な権限設定ができるシステムは多いですが、概してどれも設定が複雑になるんですよね。しかし前提知識として今回の内容程度を押さえておけば、日常運用程度ではなんとかなるし、応用も利くようになるのではないでしょうか。

| | Comments (0) | TrackBack (0)

October 04, 2010

MySQLでSLAVEサーバを作る方法

今回は、いわゆるMySQLでレプリケーションを行う方法を記してみます。非常に今更感がありますが、自分にとってかゆいところに手が届く文献がなかったので、自分でも一度まとめてみようと思いました。

【MySQLにおけるレプリケーションとは】
MySQLにおけるレプリケーションとは、マスターサーバでの更新情報がほぼリアルタイムにスレーブサーバに同期化される仕組みのことを指します。

マスターサーバ上で更新が起こると、バイナリログ(更新ログとも呼ばれる)に更新情報が記録されていきます。スレーブサーバは随時マスターサーバ上の更新情報を追いかけることでマスターサーバ上のデータをスレーブサーバ上で再現していきます。

レプリケーションにはシングルマスタ構成とマルチマスタ構成があり、通常はシングルマスタ構成を使います。シングルマスタ構成は1台のマスターサーバの下に複数台のスレーブサーバがぶらさがっているイメージです。selectなどの参照系SQLコマンドはマスターサーバでもスレーブサーバでも受け付けることができますが、insert、update、deleteといった更新系SQLコマンドはマスターサーバ上で行う必要があります。万が一更新系SQLコマンドをスレーブサーバで実行するとそのスレーブサーバにデータ不整合が起きます。

一方マルチマスタ構成は、各サーバがマスタとスレーブを兼ねるというもので、どのサーバで更新系SQLコマンドを実行しても大丈夫という仕組みです。これだけ聞くとマルチマスタ構成のほうが使い勝手が良さそうですが、シングルマスタ構成と比較すると動作が不安定とのことであまり推奨されていないようです。ですので今回はマルチマスタ構成は無視し、シングルマスタ構成についてのみ記していきます。


【レプリケーションを行う手順】
MySQLでレプリケーションを行う手順はちょっと面倒くさいです。

(1) マスタサーバ上でレプリケーションを許可するスレーブサーバの権限を付与する。
(2) マスタサーバ上でバイナリログを書き出す設定を行う。
(3) マスタサーバのテーブルへの書き込みを止め、現在のバイナリログのファイル名や位置を記録する。
(4) スレーブサーバ上で、マスターサーバを参照する設定を行う。
(5) マスタサーバのデータを、新しく構築するスレーブサーバにコピーする。
(6) スレーブサーバ上で、現在のバイナリログのファイル名や位置を先ほどコピーしたデータと合わせる。
(7) マスタサーバのテーブルへの書き込みを再開する。
(8) スレーブサーバを有効にする。

といった作業が必要になります。

ところで(2)と(3)はマスターサーバからデータや位置情報を持ってきてもいいですが、他のスレーブサーバから持ってきても良いです。稼働中のマスターサーバを止めるのは大変ですが、他のスレーブサーバであれば少しは気が楽です。


【マスターサーバからデータをコピーしてくる場合の手順】

(1) マスタサーバ上でレプリケーションを許可するスレーブサーバの権限を付与する。

mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY '';

もしくは接続を許可するIPを制限したい場合は以下のようになります。
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'192.168.0.0/255.255.255.0' IDENTIFIED BY '';

(2) マスタサーバ上でバイナリログを書き出す設定を行う。
/etc/my.cnfファイルに下記を追記します。

[mysqld]
log-bin
server-id=1

(3) マスタサーバを止め(もしくはテーブルへの書き込みを止めるだけでもOK)、現在のバイナリログのファイル名や位置を記録する。

mysql> FLUSH TABLES WITH READ LOCK;
mysql> show master status;
 
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
mysql-bin.000039 | 17510192 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

画面に出力された現在のバイナリログのファイル名(File)や位置(Position)をメモしておきます。

(4) スレーブサーバ上で、マスターサーバを参照する設定を行う。
スレーブサーバの/etc/my.cnfファイルに下記を追記します。(※server-idは他のマスター、スレーブで設定した数とは異なった数にする必要があります。1以上の整数が有効となります)

[mysqld]
server-id=2

(5) マスタサーバのデータを、新しく構築するスレーブサーバにコピーし、スレーブサーバ上で展開する。
マスターサーバ上で以下の手順を行う。

# cd /var/lib/
# tar cvf /tmp/mysql.tar mysql
# scp /tmp/mysql.tar username@slave.example.com:/tmp/
# rm -f /tmp/mysql.tar

そしてスレーブサーバ上で以下の手順を行う。

# service mysqld stop
# cd /var/lib
# mv mysql mysql_old
# tar xvf /tmp/mysql.tar
# rm -f /tmp/mysql.tar
# service mysqld start

(6) スレーブサーバ上で、スレーブサーバのステータスを確認します。

mysql> show slave status \G

*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 10.0.0.1
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000039
Read_Master_Log_Pos: 17510192
Relay_Log_File: mysqld-relay-bin.000024
Relay_Log_Pos: 80878039
Relay_Master_Log_File: mysql-bin.000039
Slave_IO_Running: No
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 17510192
Relay_Log_Space: 80878039
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL

この中の特に以下の内容が(3)でメモした内容と一致しているか確認します。

Master_Log_File: mysql-bin.000039
Read_Master_Log_Pos: 17510192

一致していなければ、現在のバイナリログのファイル名や位置を先ほどコピーしたデータと合わせます。

mysql> CHANGE MASTER TO
MASTER_HOST='10.0.0.1',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000039',
MASTER_LOG_POS=17510192;

エラーが出たら適切に対応します。

ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log
mysql> reset slave;
の後、「CHANGE MASTER TO~」を再度実行する。


(7) マスタサーバのテーブルへの書き込みを再開する。

mysq> UNLOCK TABLES;


(8) スレーブサーバを有効にする。

mysql> START SLAVE;

そしてスレーブサーバの動作を確認します。

mysql> show slave status \G

~中略~
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
~中略~


両方ともYesであれば成功です。


【スレーブサーバからデータをコピーしてくる場合の手順】
さて、次はスレーブサーバからデータをコピーしてくる場合の手順を記します。この手順が他のホームページやブログにはなかなか載ってなかったのです。とは言っても手順はほぼ同じです。違うところだけ記していきます。

(1) マスタサーバ上でレプリケーションを許可するスレーブサーバの権限を付与する。
同じ

(2) マスタサーバ上でバイナリログを書き出す設定を行う。
同じ

(3) 他のスレーブサーバを止め、現在のバイナリログのファイル名や位置を記録する。

mysql> stop slave;
mysql> show slave status;

~中略~
Master_Log_File: mysql-bin.000039
Read_Master_Log_Pos: 17510192
~中略~


画面に出力された現在のバイナリログのファイル名(File)や位置(Position)をメモしておきます。

(4) スレーブサーバ上で、マスターサーバを参照する設定を行う。
同じ

(5) 他のスレーブサーバのデータを、新しく構築するスレーブサーバにコピーし、スレーブサーバ上で展開する。
他のスレーブサーバ上で以下の手順を行う。

# service mysqld stop
# cd /var/lib/
# tar cvf /tmp/mysql.tar mysql
# scp /tmp/mysql.tar username@slave.example.com:/tmp/
# rm -f /tmp/mysql.tar
# service mysqld start

そしてスレーブサーバ上で以下の手順を行う。

# service mysqld stop
# cd /var/lib
# mv mysql mysql_old
# tar xvf /tmp/mysql.tar
# rm -f /tmp/mysql.tar
# service mysqld start

(6) スレーブサーバ上で、現在のバイナリログのファイル名や位置を先ほどコピーしたデータと合わせる。
同じ。ただ多分この作業は必要ないです。

(7)は必要なし

(8) スレーブサーバを有効にする。
同じ


【余談】
多くのサイトではマスターサーバ1台+スレーブサーバ1台の2台構成となっていると思います。しかし予備のスレーブサーバを1台足して3台構成としておくと便利です。

もし予備のスレーブサーバあると、スレーブサーバを増強しようとしたときに、本稼働中のスレーブサーバを止めずとも増強を行うことが可能となります。またバックアップや集計といったサービスとは関係ないけれども重いDB処理を行いたいときには重宝します。

| | Comments (2) | TrackBack (0)

August 13, 2009

いろいろなデータベースのバージョンの調べ方

いろいろなデータベースのバージョンの調べ方をまとめてみました。(追加すべき情報がありましたら情報提供をお待ちしております)

■MySQL
select version();


■PostgreSQL
select version();


■Oracle
select BANNER from SYS.V_$VERSION;


■SQL Server 2005
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

SQL Server 2005 SP3: 2005.90.4035
SQL Server 2005 SP2: 2005.90.3042
SQL Server 2005 SP1: 2005.90.2047


■SQL Server 2000
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

SQL Server 2000 SP4: 2000.8.00.2039
SQL Server 2000 SP3a: 2000.80.760.0
SQL Server 2000 SP3: 2000.80.760.0
SQL Server 2000 SP2: 2000.80.534.0
SQL Server 2000 SP1: 2000.80.384.0

| | Comments (2) | TrackBack (0)

August 02, 2007

MySQLのデータをシフトJISからUTF-8に変換した際の記録

今回のエントリーは、先日Shift JISで作っていたデータを多言語対応にすべくUNICODEに変換しようとしたとき苦労した際の記録です。

今回対象としたのは、MySQLからdumpした100MB近くあるデータです。

【一通りの手順】
まずMySQLからデータをdumpします。

% mysqldump [database name] > dump.sql

次にdump.sqlをmoreしてみると「DEFAULT CHARSET=sjis」という記述があるのでこれをutf8に変更します。

% perl -p -w -e 's/sjis/utf8/g' dump.sql > dump2.sql

ただいくらDEFAULT CHARSETをutf8に変えても実際のデータがシフトJISなので、データ自体もUTF-8に変えます。

% iconv -c -f shift_jis -t utf-8 dump2.sql > dump3.sql

こうして完成したデータをMySQLに読ませてみてエラーが起きなければとりあえず作業完了です。

% mysql < dump3.sql

手順をまとめてしまうとまぁ上記の通りなんですが、文字コードをシフトJISからUTF8に変えてからMySQLに読み込ませてみると通らないという点非常に苦労しました。いろいろなところで説明されているようにシフトJISからUTF8に変換する際100%全く同じに変換できない、というのがその理由です。いろいろな方が何かしらの工夫で100%に近づけるよう努力してくださった成果がiconvやnkfなどの変換コマンドなわけですが、それらのコマンドを用いてもどうもSQL文の実行に影響ある箇所で文字化けが起こってしまっていたようです。データ量が少なければ発生箇所の特定まで行いましたが今回データ量が多くかつ重要なデータでもなかったのでそこまで特定せず、iconvコマンドに-cオプション(無効な文字を無視して無視して続行することができる)をつけてごまかしています。ちなみにiconvを試す前にはnkfを試しましたが、-cオプションに相当するオプションが存在しなかったようですのでiconvを使いました。

| | Comments (2) | TrackBack (0)

May 09, 2007

データベースで大文字と小文字の区別に注意を

経験豊富なシステム管理者であれば過去にきっと1度は経験するトラブルの一つに「DBで大文字と小文字の区別をしてくれない」というものがあります。これに関連するトラブルでよくあるのは「ユーザ登録時にUSERというユーザ名でアカウントを作ったはずなのにuserでもログインできてしまう」というものがあります。予めその現象をシステム管理者が知っていれば仕様という一言で済みますが、このことを知らなかったらきっと大騒ぎとなることでしょう。

もし大文字と小文字をしっかりと区別したいのであればその解決方法がしっかり用意されています。注:ただしこの辺り実は私はあまり詳しくないのでひょっとしたら間違っている、もしくはそれは昔のことで現在のバージョンでは別の解決方法が必要になっているかもしれないので参考程度に読んでください)。

・MySQLの場合はカラム型毎に挙動が違っているらしいです。例えばTEXT型は大文字と小文字を区別しないがBOB型は区別する。varcharは大文字と小文字を区別しないがcreate tableするときにvarcharの後にBINARYをつける。

・ORACLEの場合はselectするときにUPPERやLOWERを使う。(例:select * from test_tbl where upper(name) like '%D%';)

・SQLServerの場合はデータベース作成時に照合順序をバイナリに変更してください。

など。

また同様に半角・全角の区別にも気をつけてください(ORACLEであればTO_MULTI_BYTEやTO_SINGLE_BYTEを使う)。DBって面倒くさいですね。

| | Comments (0) | TrackBack (0)

September 21, 2005

DBの時刻合わせに気をつけよう

サーバ設定に慣れた人であれば、ついついDBサーバにもNTP等を使った自動時刻をしてしまいたくなるものです。しかしDBの中には下手に時刻合わせをしてしまうとダウンしてしまうものもあるので気をつけましょう。

【時刻合わせとDBダウンの関係性】
時刻合わせと言っても、現在時刻より先に進めるパターンと過去の時刻に戻すパターンがあります。ほとんどのDBでは前者のパターンでは問題がありません。しかし気をつけなければならないのは後者のパターンです。時刻が過去に戻るとDBによってはシステム不整合と検知されダウンしてしまうものがあります(ORACLEなど)。

【DBの時刻の合わせ方】
一番安全なのは時刻合わせをする場合はメンテ日に全システムを止めた上で時刻を合わせることです。

【裏技】
しかし、そうは言ってもとめられないシステムというものもあると思います。そういった場合はこういう裏技があります。それは時刻を止めるかもしくは時刻の進行をゆっくりにしてしまうことです。ただ通常OSやDBにそういう機能はないので、何かしらのアプリケーションを探すか自作する必要があります。

※追記(2005.9.22):ntpdにはslewモードというのがありそれを使うと良いとのこと。石坂さん、上美谷さん、教えてくださってありがとうございました。

※追記(2005.9.22):WindowsTimeサービスも時刻のずれが一定時間内であれば slew モードのように動作するそうです。上美谷さん、教えてくださってありがとうございました。

| | Comments (3) | TrackBack (0)

August 23, 2005

効率的なSQL文かどうかの調査方法

ORACLE限定ですが、効率的なSQL文かどうかの調査方法をご紹介します。

SQLPlusにて

1. set autotrace on
2. set timing on

上記のコマンドをたたいてからSQLを実行すると、そのSQLの実行計画やインデックスの乗り具合が確認できます。

| | Comments (0) | TrackBack (0)

July 19, 2005

DB通信の危険性

開発者やDBAの方は普段何気なくDBにSQL文を発行してデータを取得していることが多いと思いますが、これは大変危険な行為です。そこで今回はDB通信の暗号化について記してみたいと思います。

【何が危険か】
社内にいる社員の人がデータセンターにあるDBに対して気軽にSQL文してデータを取得することの何が危険なのでしょうか。他にもあるかもしれませんが私が知る限り一番危険なのはSQL文と取得データがインターネット上を平文で流れることです。このことを気にしない、もしくは知らなかった人も多いのでは?

【施策】
おすすめする方法は次の3つです。1つだけでもいいですし、いくつか組み合わせてもよいです。

 ・VPN回線経由でSQL文発行&データ取得。
 ・踏み台サーバにSSHで接続し、そのマシン上でSQL文発行&データ取得。
 ・DB通信を暗号化することができるソリューションが導入されたクライアント&DBサーバでSQL文発行&データ取得。

【終わりに】
これだけ個人情報保護が叫ばれている中、DB通信の危険性が世の中であまり知られていないことを最近知りショックでした。皆さんどうぞお気をつけください。

| | Comments (0) | TrackBack (1)