) set @databasename='需要修复的数据库实体的名称' exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态 dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) dbcc checkdb(@databasename,REPAIR_REBUILD) exec sp_dboption @databasename, N'single', N'false'--…

由于工作需要更换公司的服务器,于是经过一堆的动作,转移网页,转移数据……正当一切都有序进行,却卡在数据库这里,一般为了方便我对数据库的备份都是复制数据库文件的,再通过附加方法实现的,今天由于发现数据库的日志文件太大就对数据库日志文件进行了减肥,结果就出现了无法附加的问题,愁死我了,后来到网上搜罗了一番,顺利的把问题解决了,现在把问题的步骤讲解一下: 1．我们使用默认方式建立一个供恢复使用的数据库(如test).可以在SQL Server Enterprise Manager里面建立. 2．停掉数…

转自:http://www.cnblogs.com/firstrose/p/4256257.html 某个SQL2000的数据库,在通过备份/还原的方法升级到2005时发生错误: 查找解决方法未果 正好最近在看 @一线码农 的<sql server之旅>,就想自己试试解决这个问题 首先运行dbcc checkdb命令,结果如下: 仔细查看出错信息,里面反复提到一个“对象 ID 2”.另外,信息里还提到“该文本的所有者是由 RID = (1:152:9) id = 213575799 and i…

一.为什么数据会不一致 回顾一下上一篇文章<缓存与数据库一致性之一:缓存更新设计>中对缓存.数据库进行读写操作的流程. 写流程: (1)先淘汰cache (2)再写db 读流程: (1)先读cache,如果数据命中hit则返回 (2)如果数据未命中miss则读db (3)将db中读取出来的数据入缓存 什么情况下可能出现缓存和数据库中数据不一致呢? 在分布式环境下,数据的读写都是并发的,上游有多个应用,通过一个服务的多个部署(为了保证可用性,一定是部署多份的),对同一个数据进行读写,在数据库层面…

默认dbcc checkdb 只做数据库的检测数据库是否完好.不会主动做数据库的修复,要修复数据库,需要数据库设单用模式. 1.repair_allow_data_loss  可能导致数据丢失. 2.Repair_fast  未执行任何修复操作. 3.repair_rebuild  快速修复. 1.repaire_allow_data_loss修复的三个过程: 第一步.将标记为不可访问的页面重新标记为可以访问,就如同这些错误从来都没有发生过一样. 第二步.用常规的日志恢复技术恢复数据库. 第三步…

使用数据库的过程中,由于断电或其他原因,有可能导致数据库出现一些小错误,比如检索某些表特别慢,查询不到符合条件的数据等. 出现这些情况的原因,往往是因为数据库有些损坏,或索引不完整. 在ACCESS中,有个修复数据库的功能可以解决这个问题,在SQL企业管理器,没有这个功能,要用语句来完成,下面就介绍如何用SQL语句完成数据库的修复,需要注意的是,在进行下面的操作时,必须断开所有用户的连接: 以下为引用的内容: USE MASTER GO sp_dboption ''你的数据库名'', ''sin…

DBCC CHECKDB 可以完成两个任务 (1)检查数据库里有没有损坏发生 (2)尽力修复数据库损坏,是数据能重新被正常访问 DBCC 下列步骤执行下列操作 1.检查一些关键性的表 sysalocunits syshobts syshobtcolumnes sysrowsets sysrowsetcolumns 2.对数据库运行DBCC CHECKALOOC 3.对数据库中的每个表和视图运行DBCC CHECKTABLE DBCC CHECKTABLE检查以下内容 是否已正确链接索引.行内.L…

今天小伙伴问了一个sql的问题: update t set status=2 where id in(select id from t where status=1) 这个sql,在并发的情况下,会不会有问题? 假设:下面的讨论,数据库的事务隔离级别是read_committed 其实这个可以很容易测试一下,得出结论:存在丢失更新的问题. 先来理解两个概念: 1. 一致性读 当前的数据库产品级别都实现了多版本一致性,即MVCC,那么有了MVCC,数据库实现了读写互不阻塞的效果. 但为了达到rea…

一般来说,如果允许缓存可以稍微的跟数据库偶尔有不一致的情况,也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话,最好不要做这个方案,即:读请求和写请求串行化,串到一个内存队列里去. 串行化可以保证一定不会出现不一致的情况,但是它也会导致系统的吞吐量大幅度降低,用比正常情况下多几倍的机器去支撑线上的一个请求. Cache Aside Pattern 最经典的缓存+数据库读写的模式,就是 Cache Aside Pattern. 读的时候,先读缓存,缓存没有的话,就读数据库,然后…

将不一致分为三种情况: 1. 数据库有数据,缓存没有数据: 2. 数据库有数据,缓存也有数据,数据不相等: 3. 数据库没有数据,缓存有数据. 在讨论这三种情况之前,先说明一下我使用缓存的策略,也是大多数人使用的策略,叫做 Cache Aside Pattern.简而言之,就是 1. 首先尝试从缓存读取,读到数据则直接返回:如果读不到,就读数据库,并将数据会写到缓存,并返回. 2. 需要更新数据时,先更新数据库,然后把缓存里对应的数据失效掉(删掉). 读的逻辑大家都很容易理解,谈谈更新.如果不采…