因为业务需要，有个临时的活动需要DBA来支持一些数据业务，问题来了，需要从MySQL端同步一部分数据到Oracle端，然后从Oracle端匹配查到相应的数据返回给MySQL，至于原因，也是不同的业务系统，不同的权限分配，还没法做到一个应用端去读取这些信息，而且也有安全的考虑，大体就是两部分的数据也是互相补充，但又彼此独立，是一个全集和子集的关系。
这个流程本来从开发的角度来看似乎是一头雾水，所以交给他们来规划就容易出现问题，最后沟通后的流程是下面的形式。
下面这个图左边是Oracle的环境，右边是MySQL的环境，两个环境的表中都存在一个共同的字段就是序列号serial_no，而且MySQL段的序列号是Oracle端的子集，两者是存在一一映射关系的。
现在的问题是MySQL端可以提供uid，但是无法得知cn_number,因为这部分信息在Oracle端。Oracle端又没有uid的概念，所以需要MySQL端提供serial_no来映射才可以。
所以一来二去，得到的流程就是需要5个步骤。
首先开发部门提供需要的uid（1），然后MySQL端抽取后把文件同步到Oracle端(2),然后在Oracle端进行关联查询，得到一个uid和cn_number的组合（3），然后同步到MySQL端，
最后MySQL端得到这部分数据，最终开发的需求就完成了。
很快就得到了MySQL端同步过来的数据，是个本文文件，内容如下：
687914 | 0d6c3956-d53d-4e14-9fba-cb73cec661e6
694786 | 41159bb3-970b-4b6b-9c5d-46e1f3d388be
746010 | 011d632d-149a-4e3d-ad00-dcae53f60825
1226533| 78dd80d3-6ad0-4bd5-aa1d-843c32b7ddab
1399846| 3dcc5982-bcc7-4cbf-9f99-b5a51b932b1d
1400221| 4fc505eb-20a6-451c-8674-5667e33167e7
因为推送过来的表的数据可能会有变化的，但是每次都去更新表的数据还是有些繁琐，一个方便的办法就是外部表了。
CREATE TABLE passport_ext
(uid number,
serial_no varchar2(100))
ORGANIZATION EXTERNAL
(TYPE ORACLE_LOADER
DEFAULT DIRECTORY ext_dir
ACCESS PARAMETERS
(
FIELDS TERMINATED BY '|'
)
LOCATION ('mysql_uid_serial_no.lst')
);
所以一旦MySQL端推送文件过来了，我只需要替换文本文件即可，然后就不用反复做数据的导入了。
直接拿过来关联即可。
但是创建外部表的时候老师抛错，最后发现uid是保留字，用下面的例子来验证。
> CREATE TABLE passport_ext (uid varchar2(10));
CREATE TABLE passport_ext (uid varchar2(10))
*
ERROR at line 1:
ORA-00904: : invalid identifier
> CREATE TABLE passport_ext (uidd varchar2(10));
Table created.
其实后面经过老猫指点，还是可以用"uid"来代替的，这个用法就跟MySQL里面的反引号类似了。
create table test1(`int` int);
Query OK, 0 rows affected (0.00 sec)
不过这个时候还是要注意。下面的输出结果，其实如果用双引号，还是不规范的，而且需要应用端去修改，这样就是一个隐藏的雷。多谢怀总指点。
SQL> create table test("uid" number);
Table created.
SQL> select uid,UID,"uid" from test;
UID UID uid
---------- ---------- ----------
0 0 1
所以在数据导入之后还是最好把字段名改过来，我就直接改成了uidd,因为字段名表关联没有强制要求uid这个列名。
关于保留字可以通过下面的方式来查询
SQL> select * from v$reserved_words where keyword='UID';
外部表加载了之后，关联的时候发现竟然没有匹配的数据，最后发现还是得trim一下数据
select t1.uidd ,t2.cn_number from passport_ext t1,passport t2 where trim(t1.serial_no)=t2.seriao_no;
通过这种方式就得到了一个数据清单，可以再次推送给MySQL端了。
这个案例还是很简单的，但是把这个过程做了多步的分解，可以看出在数据迁移中还是有很多的潜在因素需要考虑。
这个流程本来从开发的角度来看似乎是一头雾水，所以交给他们来规划就容易出现问题，最后沟通后的流程是下面的形式。
下面这个图左边是Oracle的环境，右边是MySQL的环境，两个环境的表中都存在一个共同的字段就是序列号serial_no，而且MySQL段的序列号是Oracle端的子集，两者是存在一一映射关系的。
现在的问题是MySQL端可以提供uid，但是无法得知cn_number,因为这部分信息在Oracle端。Oracle端又没有uid的概念，所以需要MySQL端提供serial_no来映射才可以。
所以一来二去，得到的流程就是需要5个步骤。
首先开发部门提供需要的uid（1），然后MySQL端抽取后把文件同步到Oracle端(2),然后在Oracle端进行关联查询，得到一个uid和cn_number的组合（3），然后同步到MySQL端，
最后MySQL端得到这部分数据，最终开发的需求就完成了。
很快就得到了MySQL端同步过来的数据，是个本文文件，内容如下：
687914 | 0d6c3956-d53d-4e14-9fba-cb73cec661e6
694786 | 41159bb3-970b-4b6b-9c5d-46e1f3d388be
746010 | 011d632d-149a-4e3d-ad00-dcae53f60825
1226533| 78dd80d3-6ad0-4bd5-aa1d-843c32b7ddab
1399846| 3dcc5982-bcc7-4cbf-9f99-b5a51b932b1d
1400221| 4fc505eb-20a6-451c-8674-5667e33167e7
因为推送过来的表的数据可能会有变化的，但是每次都去更新表的数据还是有些繁琐，一个方便的办法就是外部表了。
CREATE TABLE passport_ext
(uid number,
serial_no varchar2(100))
ORGANIZATION EXTERNAL
(TYPE ORACLE_LOADER
DEFAULT DIRECTORY ext_dir
ACCESS PARAMETERS
(
FIELDS TERMINATED BY '|'
)
LOCATION ('mysql_uid_serial_no.lst')
);
所以一旦MySQL端推送文件过来了，我只需要替换文本文件即可，然后就不用反复做数据的导入了。
直接拿过来关联即可。
但是创建外部表的时候老师抛错，最后发现uid是保留字，用下面的例子来验证。
> CREATE TABLE passport_ext (uid varchar2(10));
CREATE TABLE passport_ext (uid varchar2(10))
*
ERROR at line 1:
ORA-00904: : invalid identifier
> CREATE TABLE passport_ext (uidd varchar2(10));
Table created.
其实后面经过老猫指点，还是可以用"uid"来代替的，这个用法就跟MySQL里面的反引号类似了。
create table test1(`int` int);
Query OK, 0 rows affected (0.00 sec)
不过这个时候还是要注意。下面的输出结果，其实如果用双引号，还是不规范的，而且需要应用端去修改，这样就是一个隐藏的雷。多谢怀总指点。
SQL> create table test("uid" number);
Table created.
SQL> select uid,UID,"uid" from test;
UID UID uid
---------- ---------- ----------
0 0 1
所以在数据导入之后还是最好把字段名改过来，我就直接改成了uidd,因为字段名表关联没有强制要求uid这个列名。
关于保留字可以通过下面的方式来查询
SQL> select * from v$reserved_words where keyword='UID';
外部表加载了之后，关联的时候发现竟然没有匹配的数据，最后发现还是得trim一下数据
select t1.uidd ,t2.cn_number from passport_ext t1,passport t2 where trim(t1.serial_no)=t2.seriao_no;
通过这种方式就得到了一个数据清单，可以再次推送给MySQL端了。
这个案例还是很简单的，但是把这个过程做了多步的分解，可以看出在数据迁移中还是有很多的潜在因素需要考虑。
