在生产系统中有些时候需要保证一些表的只读特性，不允许表的数据被轻易修改。可能有一下的场景比较适用。
1） 一些系统中有一些类似数据字典信息的表。这些表的信息基本都是稳定的，不会轻易的改变。
2） 可能需要从一些外部系统中拷贝一些数据做比对和参考，不希望这些“临时”表的数据被认为修改。
3） 系统的核心表数据不想被人为的误删。
对于以上的场景可以有下面的实现思路。
1) 首先就是通过role，privilege来做限定。我们可以创建一些连接用户，这些连接用户中只存在同义词，如果只需要有只读权限，只在role中赋予select权限，或者只赋予select权限就可以了。针对第三种场景比较适用，也是比较通用的。
2)通过物化视图，对于一些表的信息，如果是稳定的，不会变化的，而且通过其他的连接用户都无法直接做更改，可以考虑使用物化视图。这对第一种场景是比较适用的。
3)alter table read only，在11g中有一个新特性，可以保证表出于只读状态，任何dml操作对它都是无效的。这对第2中场景是比较适用的
比如表TEST，如果需要设置为read only,可以写如下的sql语句。
alter table TEST read only;
4)外部表
外部表在数据迁移中，如果大家接触过比较多的迁移项目，可能就会有很真实的感受，总是有一些主键约束的数据，这些数据又很难在数据迁移之前排查出来。有些表可能比 较大，百G上T级别，如果重新导入其他的环境，又需要耗费相当多的空间，对于系统也是极大的复杂，在线业务来说不敢想象，这个时候可以考虑使用外部表。不会有物理的数据存储空间占用，外部表加载基本都是毫秒级的速度，所以对系统影响很小。同时外部表是只读的，限定了不能做数据修改。就算删除了外部表，真实的数据也不会删除， 这对于第二种场景是比较适用的，如果条件允许，对于第一种场景也是比较合适的。
1） 一些系统中有一些类似数据字典信息的表。这些表的信息基本都是稳定的，不会轻易的改变。
2） 可能需要从一些外部系统中拷贝一些数据做比对和参考，不希望这些“临时”表的数据被认为修改。
3） 系统的核心表数据不想被人为的误删。
对于以上的场景可以有下面的实现思路。
1) 首先就是通过role，privilege来做限定。我们可以创建一些连接用户，这些连接用户中只存在同义词，如果只需要有只读权限，只在role中赋予select权限，或者只赋予select权限就可以了。针对第三种场景比较适用，也是比较通用的。
2)通过物化视图，对于一些表的信息，如果是稳定的，不会变化的，而且通过其他的连接用户都无法直接做更改，可以考虑使用物化视图。这对第一种场景是比较适用的。
3)alter table read only，在11g中有一个新特性，可以保证表出于只读状态，任何dml操作对它都是无效的。这对第2中场景是比较适用的
比如表TEST，如果需要设置为read only,可以写如下的sql语句。
alter table TEST read only;
4)外部表
外部表在数据迁移中，如果大家接触过比较多的迁移项目，可能就会有很真实的感受，总是有一些主键约束的数据，这些数据又很难在数据迁移之前排查出来。有些表可能比 较大，百G上T级别，如果重新导入其他的环境，又需要耗费相当多的空间，对于系统也是极大的复杂，在线业务来说不敢想象，这个时候可以考虑使用外部表。不会有物理的数据存储空间占用，外部表加载基本都是毫秒级的速度，所以对系统影响很小。同时外部表是只读的，限定了不能做数据修改。就算删除了外部表，真实的数据也不会删除， 这对于第二种场景是比较适用的，如果条件允许，对于第一种场景也是比较合适的。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29900508/viewspace-1275893/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
oracle并行的小细节
下一篇：
使用闪回查询备份数据
请登录后发表评论
登录
全部评论
