MYSQL教程之变动Oracle数据库表的表空间

人力成本上的节省，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)上实践操纵后修正成此文。假如侵占到谁的版权，请与我接洽。
使用它开发程序也是非常简单的。”

数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

我们学到了什么？思考问题的时候从表的角度来思考问

是否碎片会引发效率问题？这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。

不过话说回来了，绝大多数的性能优化准则与对sqlserver存储的结构理解息息相关

同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。

你可以简单地认为适合的就是好，不适合就是不好。

XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！）