<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>TRACKSYSTEMS blog/jp &#187; Oracle</title>
	<atom:link href="http://www2.db-tracklayer.com/blog/jp/category/database/oracle-database/feed/" rel="self" type="application/rss+xml" />
	<link>http://www2.db-tracklayer.com/blog/jp</link>
	<description>TRACKSYSTEMS Official Blog Japanese</description>
	<lastBuildDate>Sat, 12 Mar 2011 10:30:51 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>MySQLでMyISAMとInnoDBが混在するトランザクションについて</title>
		<link>http://www2.db-tracklayer.com/blog/jp/2009/10/05/mysql%e3%81%a7myisam%e3%81%a8innodb%e3%81%8c%e6%b7%b7%e5%9c%a8%e3%81%99%e3%82%8b%e3%83%88%e3%83%a9%e3%83%b3%e3%82%b6%e3%82%af%e3%82%b7%e3%83%a7%e3%83%b3%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/</link>
		<comments>http://www2.db-tracklayer.com/blog/jp/2009/10/05/mysql%e3%81%a7myisam%e3%81%a8innodb%e3%81%8c%e6%b7%b7%e5%9c%a8%e3%81%99%e3%82%8b%e3%83%88%e3%83%a9%e3%83%b3%e3%82%b6%e3%82%af%e3%82%b7%e3%83%a7%e3%83%b3%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/#comments</comments>
		<pubDate>Mon, 05 Oct 2009 08:03:29 +0000</pubDate>
		<dc:creator>しゃちょー</dc:creator>
				<category><![CDATA[MySQL]]></category>
		<category><![CDATA[Oracle]]></category>
		<category><![CDATA[データベース]]></category>
		<category><![CDATA[InnoDB]]></category>
		<category><![CDATA[MyISAM]]></category>
		<category><![CDATA[oracle]]></category>
		<category><![CDATA[トランザクション]]></category>

		<guid isPermaLink="false">http://www2.db-tracklayer.com/blog/jp/?p=691</guid>
		<description><![CDATA[しゃちょーです。 しばらく宣伝が続いたので、DB Tracklayer開発中に気づいたちょっとおかしな感じのする話をしてみます。 MySQLでMyISAMとInnoDBが混在するトランザクションについて やっぱり今回もOracleから来た人向けの話。 Oracleの場合に（というか普通）トランザクションを考慮する時というのは、 一連の作業を一つの決定で処理したい時、またはすべき時に トランザクション中で一連の処理を行って、CommitまたはRoolbackするように処理を考える。 普通トランザクションとはこんな感じじゃないのかな。 とりあえず今回の話では、トランザクションのレベルの話とかロック関係の話は置いておいていただくとしてだ。 トランザクションは明示的に開始と終了を行いたいのであって 気にする必要があるのは、暗黙のうちにトランザクションが終了する物はないかということくらいか。（レベルとかロックの話とかは別ね） 暗黙のうちにトランザクションが終了するステートメントを把握しておかないで トランザクション中にtruncateとか書いちゃった日には、 そこまでの処理は全てcommitされて、とても悲しい結果を見ることになる。 そこさえ把握していれば別に何ら扱いにくい、という物でもない。（レベルとかロックの話とかは別ね） 上記のように扱えるのはOracleがスキーマに対してエンジンが１つだから。 私が知らないだけかもしれないが、通常Oracleを操作する上で、DBエンジンとかストレージエンジンとか意識することはないはず。 対してMySQLは、テーブル単位でストレージエンジンを設定可能なのだが これはスキーマ（データベース）の中にエンジンが混在する可能性があると言うこと。 実際そういう場合はDBの物理設計でエンジンごとに別スキーマにすべき、 と個人的には思うが、そんな物理設計が無いとは限らない。 では、たとえばMyISAMとInnoDBのテーブルが混在した処理を1つのトランザクションの中で行った場合どうなるのか？ う&#8230;即答できない&#8230; ということで、答えられないのは悔しいから実験！ 下記SQLをステップ実行した際に別セッションから見た状態で実験 ① create table test1 ( col1 int ) engine=InnoDB; ② create table test2 ( col1 int ) engine=MyISAM; ③ start transaction; ④ insert into test1 values (11); ⑤ insert [...]]]></description>
		<wfw:commentRss>http://www2.db-tracklayer.com/blog/jp/2009/10/05/mysql%e3%81%a7myisam%e3%81%a8innodb%e3%81%8c%e6%b7%b7%e5%9c%a8%e3%81%99%e3%82%8b%e3%83%88%e3%83%a9%e3%83%b3%e3%82%b6%e3%82%af%e3%82%b7%e3%83%a7%e3%83%b3%e3%81%ab%e3%81%a4%e3%81%84%e3%81%a6/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MySQLの権限周りの話はややこしい1</title>
		<link>http://www2.db-tracklayer.com/blog/jp/2009/06/05/mysql%e3%81%ae%e6%a8%a9%e9%99%90%e5%91%a8%e3%82%8a%e3%81%ae%e8%a9%b1%e3%81%af%e3%82%84%e3%82%84%e3%81%93%e3%81%97%e3%81%841/</link>
		<comments>http://www2.db-tracklayer.com/blog/jp/2009/06/05/mysql%e3%81%ae%e6%a8%a9%e9%99%90%e5%91%a8%e3%82%8a%e3%81%ae%e8%a9%b1%e3%81%af%e3%82%84%e3%82%84%e3%81%93%e3%81%97%e3%81%841/#comments</comments>
		<pubDate>Fri, 05 Jun 2009 06:16:40 +0000</pubDate>
		<dc:creator>しゃちょー</dc:creator>
				<category><![CDATA[MySQL]]></category>
		<category><![CDATA[Oracle]]></category>
		<category><![CDATA[データベース]]></category>
		<category><![CDATA[grant]]></category>
		<category><![CDATA[ユーザ]]></category>
		<category><![CDATA[ユーザID]]></category>
		<category><![CDATA[権限]]></category>

		<guid isPermaLink="false">http://www2.db-tracklayer.com/blog/jp/?p=403</guid>
		<description><![CDATA[しゃちょーどす。 いやーMySQLのこと書くのとか面倒くさくなってきたな。なんちって。 今回はユーザの権限周りの話。 その4：MySQLの権限周りの話はややこしい1 これはいつもいつも結構引っかかってる人多いですな。 特にOracle経験者の方。 MySQLの権限のコントロールは下記のような感じ（厳密にはそういうサイトにどうぞ）で行われる ・接続時にユーザID（ユーザ＋ホスト）で接続する権限があるかをチェック ・接続後のすべてのリクエスト時にユーザID（ユーザ＋ホスト）にリクエストを実行する権限があるかをチェック これを分解して説明してみる。 ・接続時にユーザID（ユーザ＋ホスト）で接続する権限があるかをチェック 単純なことなんだが、MySQLが接続チェックに使用するキーは、ユーザではなくてユーザ＋ホストであるということ。 権限を設定するのも当然ユーザ単位ではなくてユーザ＋ホスト単位であるということ。 このユーザ＋ホストの組み合わせをMySQLではユーザIDと言っている。 shachoユーザがアクセスするときの例としてはこんな感じ shacho@'%' すべてのホストからアクセス可能 shacho@localhost ローカルホスト(サーバーそのもの)のみアクセス可能 shacho@'192.168.1.99' IPアドレス192.168.1.99のホストよりアクセス可能 shacho@'tracksys.jp' ドメイン名tracksys.jpからアクセス可能 上記4例はMySQLが接続チェックする際にはすべて別のユーザIDとして扱われる。 例えば下記のGrant文を実行した際には、shachoユーザはlocalhostからのみすべてのDBにすべての権限でアクセスできる。 GRANT ALL ON *.* TO shacho@localhost IDENTIFIED BY 'password' 分解すると ALL： すべての権限を付与 ON *.*： すべてのDBのすべてのオブジェクトへのアクセスを許可 TO shacho@localhost：shachoユーザに付与。ただしlocalhostからのアクセスに限る となる。 localhostだけではなくて同じサブネットのホストからもアクセスできるように設定する GRANT SELECT ON *.* TO shacho@'192.168.1.%' IDENTIFIED BY 'password' 権限をSELECTのみに設定したため、shachoユーザがlocalhost以外の同一サブネットから接続した場合には検索しかできない。 このように、ユーザIDに対して異なる権限を設定できるのだが、ここでユーザIDとユーザ（shachoとかrootとか）を混同していると、きわめて深い沼に沈むことになる。 [...]]]></description>
		<wfw:commentRss>http://www2.db-tracklayer.com/blog/jp/2009/06/05/mysql%e3%81%ae%e6%a8%a9%e9%99%90%e5%91%a8%e3%82%8a%e3%81%ae%e8%a9%b1%e3%81%af%e3%82%84%e3%82%84%e3%81%93%e3%81%97%e3%81%841/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>データベース（Database）とスキーマ（Schema）とユーザ（User）の関係</title>
		<link>http://www2.db-tracklayer.com/blog/jp/2009/06/03/374/</link>
		<comments>http://www2.db-tracklayer.com/blog/jp/2009/06/03/374/#comments</comments>
		<pubDate>Wed, 03 Jun 2009 08:29:27 +0000</pubDate>
		<dc:creator>しゃちょー</dc:creator>
				<category><![CDATA[MySQL]]></category>
		<category><![CDATA[Oracle]]></category>
		<category><![CDATA[データベース]]></category>
		<category><![CDATA[Instance]]></category>
		<category><![CDATA[Schema]]></category>

		<guid isPermaLink="false">http://www2.db-tracklayer.com/blog/jp/?p=374</guid>
		<description><![CDATA[しゃちょーです。 連続投稿で翻訳担当から怒られそうですが、まあ気にせず書いていきますよ。 今回のMySQL超初心者Tipsは OracleからMySQLに移行してきた人が一番気持ち悪くなるネタ、DBとスキーマとユーザについての話を。 その3：データベース（Database）とスキーマ（Schema）とユーザ（User）の関係 Schemaについて諸説いろいろだが、Oracleの場合にはDatabaseの中の、あるUserが所有しているオブジェクト群 を示していると思う。微妙に違うが、単位のレベルとしてはUserとSchemaは同列だ。 オブジェクトの参照は、Database名.Schema名（ユーザ名）.Object名となる。 MySQL場合はDatabaseとSchemaが同等で、UserはInstanceに対して設定するものなので ObjectはUserのもとに属さないことになる。 オブジェクトの参照は、Database名（Schema名）.Object名 となる。 加えて言うと、Oracleの場合はDatabase=1つのInstanceとなるが MySQLの場合は1つのInstanceの中に多数のDatabaseを作成することができる。 乱暴な言い方をすればOracleのDatabaseはMySQLのInstanceだ、といえるはず（凄く乱暴だが）。 これがOracle技術者がMySQLを触り始めたときに一番気持ち悪いところだと思われる。 単純に言葉の定義が違うとあきらめた方が良いかと思う。 次回はこれをふまえてさらにMySQLのユーザ関係をややこしくしてしまう、ユー権限周りについて少し書いてみようかな。]]></description>
		<wfw:commentRss>http://www2.db-tracklayer.com/blog/jp/2009/06/03/374/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>varchar型のカラムで大文字小文字が区別されない（検索時のケース非依存）</title>
		<link>http://www2.db-tracklayer.com/blog/jp/2009/06/02/369/</link>
		<comments>http://www2.db-tracklayer.com/blog/jp/2009/06/02/369/#comments</comments>
		<pubDate>Tue, 02 Jun 2009 08:48:49 +0000</pubDate>
		<dc:creator>しゃちょー</dc:creator>
				<category><![CDATA[MySQL]]></category>
		<category><![CDATA[Oracle]]></category>
		<category><![CDATA[データベース]]></category>
		<category><![CDATA[binary]]></category>
		<category><![CDATA[varchar]]></category>
		<category><![CDATA[ケース非依存]]></category>
		<category><![CDATA[大文字小文字]]></category>

		<guid isPermaLink="false">http://www2.db-tracklayer.com/blog/jp/2009/06/02/369/</guid>
		<description><![CDATA[しゃちょーです。 じゃんじゃんいきます。 今回もMySQLの超初心者Tips。 今回のネタは、MySQL自身がドキュメントでそう謳っているので仕様なんだけど、Oracle技術者の人にはあり得ない仕様らしくて、まさかそれがオプションだと思っていない人が多いので。 そんなこと言ったって仕様は仕様でしょ？しょうがないじゃん。 公式ドキュメントをちゃんと読めばわかるんだけど、みんな読まないよね。 気持ちわかりますよ。（でも読んだ方がいいよ） その2：varchar型のカラムで大文字小文字が区別されない（検索時のケース非依存） これはほぼ毎回聞かれるね。 MySQLのドキュメントでは「検索時のケース依存」（Case Sensitivity in Searches）という言い方をしている。 あまりにFAQなのでまさかと思って自分からは言わないが、 テストに入ったあたりで、 「where句に指定した文字列が大文字小文字の別なくマッチするんですけど、まさかMySQLって大文字小文字の区別しないんじゃないでしょうね？」 てな感じでさも私が作ったものであるかのように詰問される。 「binary属性つけてください」 char型も同じですから。 これから作るなら Create Table テーブル名 (カラム名 varchar(n) BINARY); もう作り直せないってなら Alter Table テーブル名 MODIFY カラム名 varchar(n) BINARY; 以下はOracle技術者向けの例。 &#8211; col1をbinary属性付きで、col2をデフォルトのままでテーブルを作成 mysql&#62; Create Table tab1 (col1 varchar(10) BINARY, col2 varchar(10)); Query OK, 0 rows affected (0.19 sec) mysql&#62; show [...]]]></description>
		<wfw:commentRss>http://www2.db-tracklayer.com/blog/jp/2009/06/02/369/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

