仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 1036|回复: 8
打印 上一主题 下一主题

[学习教程] MYSQL教程之变动Oracle数据库表的表空间

[复制链接]
再现理想 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:31:58 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
人力成本上的节省,MySQL的用户Spacemonkey实验室的首席执行官MitchPirtle如此表示:“维护MySQL使得你不需要一个年薪15万美元的DBA。oracle|数据|数据库
在Oracle数据库办理体系中,创立库表(table)时要分派一个表空间(tablespace),假如未指定表空间,则利用体系用户确省的表空间。

在Oracle实践使用中,我们大概会碰到如许的成绩。处于功能大概其他方面的思索,必要改动某个表大概是某个用户的一切表的表空间。一般的做法就是起首将表删除,然后从头建表,在新建表时将表空间指定到我们必要改动的表空间。假如该用户已保留了大批数据,这类举措就就显得不是很便利,由于有大批数据必要提早备份出来。上面先容一种使用数据库的导出/导进功效来完成从头构造数据库表空间的办法。

上面是一个复杂的例子,假定要将用户oa下的全体表从表空间A转换到表空间B,详细步骤(在Oracle9iforlinux情况)以下:
1.1.导出db_zgxt下的一切表(Dos把持台下)导出db_zgxt下的一切表(Dos把持台下)1.导出db_zgxt下的一切表(Dos把持台下)
EXPoa/password@pararmount_serverFILE=d:10_27_oa.dmpLOG=d:10_27_oa.LOG


2.删除oa下的一切表(在SQL/PLUS中)

能够接纳批处置的体例删撤除db_zgxt下的一切表,天生批处置的语句以下:
--个中setheadoff将表头信息往失落
SETHEADOFF
SPOOLc:drop_tables.sql
selectdroptable||table_name||;fromuser_tables;
spooloff;
@c:drop_tables.sql;
sql>@drop_tables.sql
3.接纳导进参数INDEXFILE导进oa用户下的一切表(Dos把持台下)
把建表和索引的语句导出到文件,个中建表语句是加正文的,并没有实践导进

IMPoa/password@paramount_serverFULL=YFILE=d:10_27_oa.dmpINDEXFILE=d:altertablespace_table_index.SQLLOG=d:altertablespace.LOG


个中,指定参数INDEXFILE后,体系就将创立表和索引的语句写到一个文件,这里是altertablespace_table_index.SQL中。该文件中包括了一切创立索引(CREATEINDEX)语句和创立表(CREATETABLE)语句,可是这里一切创立表的语句均加了正文标记。在任何文本编纂器中翻开并编纂该文件,往失落一切创立表语句的正文标记,将一切的表空间称号由A交换为B,同时对一切的创立索引语句加上正文标记。这些事情作完今后,在SQL/PLUS中运转该剧本文件,这些表就被创立,其表空间由A变成B。
接纳导进参数INDEXES=N和IGNORE=Y将db_zgxt用户的表数据导进库中(Dos把持台下)
4.接纳导进参数INDEXES=N和IGNORE=Y将oa用户的表数据导进库中(Dos把持台下)

IMPoa/password@paramount_serverFULL=YINDEXES=NFILE=d:10_27_oa.dmpIGNORE=YLOG=d:altertablespace.LOG

个中,参数INDEXES=N是指将数据导进数据库中时不加索引。IGNORE=Y是指在导进数据过程当中,疏忽表已存在(tablealreadyexists)的毛病。如许Oralce就将数据和一些束缚前提导进到第3步创立的表中。


5.创立索引

在文本编纂器中从头翻开在第3步中创立的altertablespace_table_index.SQL剧本文件,此次,将一切创立表(CREATETABLE)的语句加上正文标记,然后将一切的创立索引(CREATEINDEX)语句往失落正文标记。在SQL/PLUS中再次运转该剧本文件。

至此,我们就乐成完成了将oa用户下的全体表从表空间A转换到表空间B的事情。固然你能够只导进一部分表。

注:本文参考网上搜到的一篇文章,自己在更新的平台(oracle9i)上实践操纵后修正成此文。假如侵占到谁的版权,请与我接洽。
使用它开发程序也是非常简单的。”
蒙在股里 该用户已被删除
沙发
发表于 2015-1-19 16:13:01 | 只看该作者
数据库物理框架没有变动undo和redo都放在数据库得transaction中,个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库,可能能在一定程度上避免I/O效率问题。
爱飞 该用户已被删除
板凳
发表于 2015-1-28 06:09:52 | 只看该作者
但是随着数据量的增大,这种成本差距会逐渐减小,趋于相等。(500万数量级只相差10%左右)
小妖女 该用户已被删除
地板
发表于 2015-2-5 17:01:02 | 只看该作者
我们学到了什么?思考问题的时候从表的角度来思考问
透明 该用户已被删除
5#
发表于 2015-2-12 23:55:21 | 只看该作者
是否碎片会引发效率问题?这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。
山那边是海 该用户已被删除
6#
发表于 2015-3-3 11:41:41 | 只看该作者
不过话说回来了,绝大多数的性能优化准则与对sqlserver存储的结构理解息息相关
若相依 该用户已被删除
7#
发表于 2015-3-11 10:39:56 | 只看该作者
同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中,就能感觉到目前架构的尴尬。
柔情似水 该用户已被删除
8#
发表于 2015-3-18 07:03:11 | 只看该作者
你可以简单地认为适合的就是好,不适合就是不好。
金色的骷髅 该用户已被删除
9#
发表于 2015-3-25 13:24:22 | 只看该作者
XML字段类型更好的解决了XML数据的操作。XQuery确实不错,但是个人对其没好感。(CSDN的开发者应该是相当的熟了!)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-23 11:34

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表