仓酷云

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

[学习教程] MSSQL网页编程之数据库恢复一例(1)

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

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

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

x
闪回的目的是要让数据库在commit之后,还能恢复到之前的某个状态,整库或指定的表。恢复|数据|数据库
oracle9i回滚段表空间丧失后的处置办法:

用隐含参数恢单数据库的例子:

详细操纵步骤以下:

起首把初init.ora文件里主动办理改成手工办理,然后到场隐含参数:
#undo_management=AUTO
undo_tablespace=UNDOTBS
_corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)

SQL>startupmount(数据库启动到mount形态)
SQL>alterdatabasedatafileD:ORACLEORADATAORCLUNDOTBS01.DBFofflinedrop;
Databasealtered.

SQL>alterdatabaseopen;
Databaseopened.
SQL>showparameterundo

NAMETYPEVALUE
--------------------------------------------------------
undo_managementstringMANUAL
undo_retentioninteger900
undo_suppress_errorsbooleanFALSE
undo_tablespacestringUNDOTBS

SQL>droptablespaceundotbsincludingcontents;
Tablespacedropped.

重修undotbs表空间:
SQL>createundotablespaceundotbsdatafileD:ORACLEORADATAORCLUNDOTBS01.DBF
size100M;
Tablespacecreated.

SQL>shutdownimmediate(封闭数据库)
Databaseclosed.
Databasedismounted.
ORACLEinstanceshutdown.

编纂init.ora初始化参数文件,往失落隐含参数,设置
undo_management=AUTO
undo_tablespace=UNDOTBS
保留init.ora文件,然后实行
SQL>startupmount
ORACLEinstancemounted.
TotalSystemGlobalArea114061244bytes
FixedSize282556bytes
VariableSize79691776bytes
DatabaseBuffers33554432bytes
RedoBuffers532480bytes
Databasemounted.

SQL>alterdatabasedatafileD:ORACLEORADATAORCLUNDOTBS01.DBFonline;
Databasealtered.

SQL>alterdatabaseopen;
Databaseopened.
SQL>showparameterundo

NAMETYPEVALUE
-----------------------------------------------------------------------------
undo_managementstringAUTO
undo_retentioninteger900
undo_suppress_errorsbooleanFALSE
undo_tablespacestringUNDOTBS
因此我们看到,这些信息足够让我们对单个操作实现“逆操作”。
活着的死人 该用户已被删除
沙发
发表于 2015-1-19 17:46:51 | 只看该作者
这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高,但是相对映射到数据表中效率还是提高了很多。我做过试验,在我的实验环境中会比映射到表中提高30%左右的效率。
莫相离 该用户已被删除
板凳
发表于 2015-1-24 15:41:18 | 只看该作者
多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助,但是感觉粒度还是不太细。
若天明 该用户已被删除
地板
发表于 2015-2-1 23:35:36 | 只看该作者
无法深入到数据库系统层面去了解和探究
深爱那片海 该用户已被删除
5#
发表于 2015-2-7 16:12:30 | 只看该作者
换言之,只有在不断的失败中尝试成功,而关于失败的总结却是很少的
分手快乐 该用户已被删除
6#
发表于 2015-2-22 14:47:04 | 只看该作者
至于淘汰的问题,只能说在你的项目周期之内,微软应该都不会倒闭。
兰色精灵 该用户已被删除
7#
发表于 2015-3-7 00:46:29 | 只看该作者
原来的计算字段其实和虚拟字段很像。只是管理方面好了而已,性能方面提高不多。但是SQL2005提供了计算字段的持久化,这就提高了查询的性能,但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。
简单生活 该用户已被删除
8#
发表于 2015-3-13 23:45:44 | 只看该作者
这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据,是否会出现大规模的碎片?
变相怪杰 该用户已被删除
9#
发表于 2015-3-20 23:30:07 | 只看该作者
这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高,但是相对映射到数据表中效率还是提高了很多。我做过试验,在我的实验环境中会比映射到表中提高30%左右的效率。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

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

GMT+8, 2024-12-22 23:28

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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