MYSQL编程：ORACLE 回滚段表空间数据文件丧失或破坏...

怀疑这些功能在MySQL5.0中的成熟性。充其量它们在MySQL中被支持的时间也就一年左右，而在MySQL学习教程其他关系型数据库中则已经存在了近10年的时间。oracle|数据
成绩形貌：
这是一个回滚段表空间数据文件丧失或破坏的情形，这时候oracle不克不及辨认响应的数据文件。当你试图startup数据文件时会报ORA-1157，ORA-1110，而且大概会陪伴着标识操纵体系级其余毛病，好比ORA-7360。当你试图以shutdownnormal或shutdownimmediate形式封闭数据库时会导至ORA-1116,ORA-1110,并大概陪伴标识操纵体系级其余毛病，好比ORA-7368，偶然以一般体例shutdown数据库基本shutdown不上去。

告诫：
文章中所说起的步骤是供oracle的环球手艺撑持利用的。出格是步骤6中的_corrupted_rollback_segments参数，利用后必要重修数据库，在利用这个参前请察看一下一切别的的选项。

办理办法注释：

以下的办理办法取于检测成绩呈现时数据库所处于形态:

I.数据库是处于封闭形态的。
试图翻开数据库时报ORA-1157和ORA-1110毛病，这时候的办理办法取于数据库是不是是一般shutdown的(利用normal或immediate选项。

I.A.数据库是一般shutdown的

假如数据数据库是一般shutdown的，最复杂的办理办法是以offlinedrop选项删除丧失或破坏的数据文件，以restriceted形式打个数据库，删除偏重建这个数据文件所属的谁人回滚表空间。假如数据库是以shutdownabort或本人溃散失落的则不要遵守这个历程。

步骤以下：

1、确认数据库是一般shutdown的。能够反省alter.log这个文件，定位到最初几行看是不是能够看到以下的信息：
"alterdatabasedismount
Completed:alterdatabasedismount"

这固然也包含以一般体例shutdown,接然试图启动数据库确失利的情况。假如比来一次你是以shutdownabort体例封闭数据库的或数据库是本人crashed失落的，你使用利用上面的I.B的办法。

2、在init<sid>.ora中把属于丧失数据文件的回滚段从ROLLBACK_SEGMENTS参数中往失落。假如你不克不及确信是哪一个回滚段，能够复杂的把ROLLBACK_SEGMENTS这个参数正文失落。

3、以restricted形式mount数据库
STARTUPRESTRICTMOUNT;

4、Offlinedrop丧失或破坏的谁人数据文件。
ALTERDATABASEDATAFILE<full_path_file_name>OFFLINEDROP;

5、翻开数据库
ALTERDATABASEOPEN；
假如前往"Statementprocessed"这条信息，转到第7步.
假如失掉ORA-604,ORA-376,和ORA-1110毛病，转到第6步。

6、由于翻开数据库失利，shutdown失落数据库而且编纂int<SID>.ora这个文件。正文失落ROLLBACK_SEGMENTS这个参数，而且在init<SID>.ora文件中到场以下一行：
_corrupted_rollback_segments=(<rollback1>,...,<rollbackN>)
这个参数应该包括ROLLBACK_SEGMENTS中一切的回滚段。

必要注重的是这个参数只能在指定的情形下或在oracle的环球持术撑持的引导下才应利用，然后以restricted形式翻开数据库：


STARTUPRESTRICT

7、删撤除谁人文件所属的回滚段表空间。
DROPTABLESPACE<tablespacename>INCLUDINGCONTENTS;

8、重修回滚段表空间及回滚段，创立完后使它们online.

9、使数据库一切用户都可用。
ALTERSYSTEMDISABLERESTRICTEDSESSION;

10、在init<SID>.ora中把你从头创立的回滚段再一次包含出去，假如你利用了第6步则移撤除CORRUPTED_ROLLBACK_SEGMENTS这个参数。


I.B.数据库不是一般shutdown的

这类情形，数据库比来一次是用shutdownabort或crashed失落封闭，回滚段中几近必定包括着举动的事件。因而，坏的谁人数据文件不克不及脱机(offline)或是drop失落，你必须从备份恢复这个文件。假如数据为是处于非回档形式的，只要比来的一些事件日记还没有被重写失落的情形你才干乐成恢复这个文件。假如这个文件的备份也是有效的，接洽一下oracle的手艺撑持吧。

步骤以下：

1、从备份中恢复丧失的谁人数据文件.

2、mount上数据库

3、实行以下的查询：
SELECTFILE#,NAME,STATUSFROMV$DATAFILE;
假如数据文件的形态是offline的，你必须先把它联机了：
ALTERDATABASEDATAFILE<full_path_file_name>ONLINE;

4、实行以下的查询：

SELECTV1.GROUP#,MEMBER,SEQUENCE#,FIRST_CHANGE#
FROMV$LOGV1,V$LOGFILEV2
WHEREV1.GROUP#=V2.GROUP#;

这将列出一切的联机的重做日记和他们的序号及初次改动号(firstchangenumbers).

5、假如这个数据库长短回档形式的，实行以下的查询：
SELECTFILE#,CHANGE#FROMV$RECOVER_FILE;
假如个中的CHANG#比4中的最小的谁人FIRST_CHANGE#年夜的话，用联机日记就能够完成恢复。

6、假如CHANG#比4中的最小的谁人FIRST_CHANGE#小，则数据库是不克不及恢复的，能够接洽一下oracle的手艺撑持。

译者拔出：假如你真长短回档体例且这个文件的备份也是有效的，假如你以为能够丧失回滚段中的那事件，你能够用I.A中从第6步的办法，这时候能够翻开数据库，应当即做一个备份，由于库中的数占有些纷歧致。

RECOVERDATAFILE<full_path_file_name>

7、确认一切的日记都被恢复，只到你收到"Mediarecoverycomplete"信息。

8、翻开数据库


待续
你不用花费很多时间和金钱来培训现有的职工，或者去花大价钱雇用那些拥有各种证书的开发者。因为MySQL的维护和管理在很大程度上是“傻瓜型”的。

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

多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。

也可谈一下你是怎么优化存储过程的?

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

大家注意一点。如下面的例子：

大家注意一点。如下面的例子：

不好!如果出了错;不好调试;不好处理!其实web开发将代码分为3层:web层;业务逻辑层和数据访问层;一般对数据库的操作都在数据访问层来做;这样便于调试和维护!而且将来如果是换了数据库的话;你只需要改数据层的代码;其他层的基本可以不变!要是你在jsp中直接调用sql数据库;那么如果换了数据库呢?岂不都要改?如果报了异常呢?怎么做异常处理?

分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。