标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,767)
- DB2 (22)
- MySQL (77)
- Oracle (1,608)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (590)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
分类目录归档:SQL Server
由于文件组 ‘DEFAULT’ 中的磁盘空间不足,无法为数据库 ‘TEMPDB’ 分配新页
今天接到一个朋友的问题,sql server报“由于文件组 ‘DEFAULT’ 中的磁盘空间不足,无法为数据库 ‘TEMPDB’ 分配新页”,按照错误提示应该是tempdb空间不足,让其查看tempdb对应数据库文件大小为不到4g,查看其对应文件为自增长,硬盘空间还有40g多点,那应该没有问题。后来她说该文件所处位置的盘是fat32的,那问题确定是fat32最大支持文件大小是4g。解决办法:
1、让tempdb中的文件恢复默认值,设置其最大值
1)重启sql server服务,tempdb一般会自动变为初始化大小
2)如果1)失败,使用下面语句
dbcc shrinkfile (tempdev, 10)
dbcc shrinkfile (templog, 10)
2)然后设置tempdev和templog的最大大小为4000m
2、添加数据文件和日志文件,并设置其最大值为4000m
3、修改程序,从根源上解决问题
分析产生该问题原因
询问朋友后,原来是她对一个6kw的表和1kw的表进行关联,然后取得需要的数据插入到另一张表中,因为涉及的数据量非常大,所有导致tempdb数据库飞速增大,超过系统文件大小限制。导致文章开始的错误,光添加文件,对于这么大数据量的程序来说还是不能解决问题。应该在程序上去优化,而不是靠添加tempdb中文件的大小和数量来解决问题。
添加程序的提交次数,而不是所有数据一次提交,放在一个事物中。
我根据程序需求模拟的写了两种处理过程的方法
模拟环境:
--创建模拟表 SELECT id,name INTO t_1 FROM sys.sysobjects; SELECT object_id id,name INTO t_2 FROM sys.columns; --创建跟踪表 CREATE TABLE t_s (id int DEFAULT 0,date datetime DEFAULT getdate()); INSERT INTO t_s VALUES(0,getdate()); --创建需要插入数据表 SELECT t1.name n1, t2.name n2, t1.id INTO test_1 FROM t_1 t1, t_2 t2 WHERE t1.id = t2.id AND 1=2;
方法一:
特点:1、优点执行效率比较高,无需排序和插入跟踪表
2、缺点:不能查看程序执行进度,如果异常终止,必须重新执行
create PROCEDURE [dbo].[INSERT_d_1] AS DECLARE @name1 varchar(4000) DECLARE @name2 varchar(4000) DECLARE @id int DECLARE c1 CURSOR FOR SELECT t1.name, t2.name, t1.id FROM t_1 t1, t_2 t2 WHERE t1.id = t2.id ORDER BY t1.id open c1 fetch next from c1 into @name1,@name2,@id WHILE @@fetch_status=0 BEGIN INSERT INTO test_1 VALUES(@name1,@name2,@id) FETCH next FROM c1 INTO @name1,@name2,@id END CLOSE c1 DEALLOCATE c1
方法二:
特点:1、可以跟踪程序的执行进度查询t_s表,如果异常终止可以写其他程序继续
2、程序使用二重游标,执行效率比较低
create PROCEDURE [dbo].[INSERT_d_2] AS DECLARE @name1 varchar(4000) DECLARE @name2 varchar(4000) DECLARE @id int DECLARE c1 CURSOR FOR SELECT t1.name, t1.id FROM t_1 t1 ORDER BY t1.id open c1 fetch next from c1 into @name1,@id WHILE @@fetch_status=0 BEGIN --二重循环 DECLARE c2 CURSOR FOR SELECT t2.name FROM t_2 t2 WHERE t2.id=@id OPEN c2 FETCH next FROM c2 INTO @name2 WHILE @@FETCH_STATUS=0 BEGIN INSERT INTO test_1 VALUES(@name1,@name2,@id) UPDATE t_s SET id=@id,date=getdate() FETCH next FROM c2 INTO @name2 END CLOSE c2 DEALLOCATE c2 FETCH next FROM c1 INTO @name1,@id END CLOSE c1 DEALLOCATE c1
发表在 SQL Server
评论关闭
sql server 2005镜像配置
1、服务器ip地址和数据库版本
主机:192.168.1.1
备机:192.168.1.110
数据库:sql server 2005 sp4
2、主备实例互通
1)创建证书
--主机执行 USE MASTER GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'xifenfei'; GO USE MASTER GO CREATE CERTIFICATE HOST_A_cert WITH SUBJECT = 'A certificate for database mirroring', START_DATE = '11/25/2009', EXPIRY_DATE = '12/31/2199'; GO --备机执行 USE MASTER GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'xifenfei'; GO USE MASTER GO CREATE CERTIFICATE HOST_B_cert WITH SUBJECT = 'A certificate for database mirroring', START_DATE = '11/25/2009', EXPIRY_DATE = '12/31/2199'; GO
2)创建连接的端点
--主机执行 create endpoint endpoint_mirroring state=started as tcp (listener_port=5022,listener_ip=all) for database_mirroring (authentication=certificate HOST_A_cert,encryption=supported,role=all); --备机执行 create endpoint endpoint_mirroring state=started as tcp (listener_port=5022,listener_ip=all) for database_mirroring (authentication=certificate HOST_B_cert,encryption=supported,role=all);
3)备份证书以备建立互联
--主机执行 backup certificate HOST_A_cert to file='E:\database\key\HOST_A_cert.cer'; --备机执行 backup certificate HOST_B_cert to file='C:\database\mssql\key\HOST_B_cert.cer';
4)互换备份证书
拷贝证书文件到对象文件夹中
5)添加登录名、用户
--主机执行 create login HOST_B_login with password='20091125'; create user HOST_B_user for login HOST_B_login; create certificate HOST_B_cert authorization HOST_B_user from file='C:\database\mssql\key\HOST_B_cert.cer'; grant connect on endpoint::endpoint_mirroring to [HOST_B_login]; --备机执行 create login HOST_A_login with password='20091125'; create user HOST_A_user for login HOST_A_login; create certificate HOST_A_cert authorization HOST_A_user from file='E:\database\key\HOST_A_cert.cer'; grant connect on endpoint::endpoint_mirroring to [HOST_A_login];
3、建立镜像关系
1)备份还原数据库
/*尝试从刚刚使用的全备文件进行还原,在还原数据的时候需要使用”WITH NO RECOVERY“选项。*/ --主机执行 backup database test to disk='D:\sqlbackup\test091124full.bak' backup log test to disk='D:\sqlbackup\test091124log.bak' --备机执行 restore database acmr_10jqka from disk='D:\sqlbackup\test091124full.bak' with replace,norecovery restore log acmr_10jqka from disk='D:\dbbackup\118_sql\acmr_10jqka091125log.bak' with norecovery
2)建立镜像
/*注意:先备机,后主机*/ --备机执行 alter database acmr_10jqka set partner='TCP://192.168.1.1:5022'; --主机执行 alter database test set partner='TCP://192.168.1.110:5022';
3)事务安全性设置
/*默认情况下,事务安全级别的设置为FULL,即“同步运行模式”,而且,SQL SERVER 2005标准版只支持同步模式。*/ /*如果关闭事务安全级别FULL模式,则可以切换到异步运行模式,该模式可使性能达到最佳。*/ --主机执行 use master go alter database test set partner safety full; --事务安全,同步模式 alter database test set partner safety off; --事务不安全,异步模式
4)切换
--主机执行下面命令后,即切换为备机角色 use master go alter database test set partner failover; /*同理,也可以在备机(主体数据库)上执行上面命令,之后切换为备机(备数据库)*/
发表在 SQL Server
评论关闭
SQL Server恢复模式
一、查询现有数据库恢复模式
1、直接查看
1).展开“数据库”,然后根据数据库的不同,选择用户数据库,或展开“系统数据库”,再选择系统数据库。
2).右键单击该数据库,再单击“属性”,这将打开“数据库属性”对话框。
3).在“选择页”窗格中,单击“选项”。
4).当前恢复模式显示在“恢复模式”列表框中。
5).也可以从列表中选择不同的模式来更改恢复模式。可以选择“完整”、“大容量日志”或“简单”。
2、通过sql语句查看
--sql server 2000及其以前版本 SELECT name, (SELECT DATABASEPROPERTYEX(name, 'RECOVERY')) RecoveryModel FROM master.sys.databases ORDER BY name --sql server 2005及其以后版本 SELECT name, recovery_model_desc FROM master.sys.databases ORDER BY name
二、三种恢复模式比较
1、简单恢复模式
特点:无日志备份。自动回收日志空间以减少空间需求,实际上不再需要管理事务日志空间。
工作丢失的风险 :最新备份之后的更改不受保护。在发生灾难时,这些更改必须重做。
能否恢复到时点:只能恢复到备份的结尾
降低工作丢失风险:不影响备份管理的前提下时常备份,以免丢失大量数据。
适用范围(符合下列所有要求):
1.不需要故障点恢复。如果数据库丢失或损坏,则会丢失自上一次备份到故障发生之间的所有更新,但您愿意接受这个损失。
2.您愿意承担丢失日志中某些数据的风险。
3.您不希望备份和还原事务日志,希望只依靠完整备份和差异备份。
2、完整恢复模式
特点:需要日志备份。数据文件丢失或损坏不会导致丢失工作。可以恢复到任意时点(例如应用程序或用户错误之前)。
工作丢失的风险:正常情况下没有。如果日志尾部损坏,则必须重做自最新日志备份之后所做的更改。
能否恢复到时点:果备份在接近特定的时点完成,则可以恢复到该时点。
时点恢复:出现故障后,可以尝试备份“日志尾部”(尚未备份的日志)。如果结尾日志备份成功,则可以通过将数据库还原到故障点来避免任何工作丢失。
缺点:使用日志备份的缺点是它们需要使用存储空间并会增加还原时间和复杂性。
一般的备份策略:
1.首先完整备份数据库以及日志备份.
2.在日志备份后的某个时间,数据库发生错误.接下来 先备份活动日志
3.然后还原完整数据库备份和日志备份,但是不恢复数据库;
4.还原并恢复结尾日志备份。这样就完成了恢复待故障点,恢复了所有数据.
降低工作丢失风险:建议经常执行日志备份,以将工作丢失的风险限定在业务要求所允许的范围内。
适用范围(符合下列任一要求):
1.您必须能够恢复所有数据
2.数据库包含多个文件组,并且您希望逐段还原读/写辅助文件组(以及可选地还原只读文件组)。
3.您必须能够恢复到故障点
4.您希望可以还原单个页
5.您愿意承担事务日志备份的管理开销。
3、大容量日志会恢复
特点:需要日志备份。是完整恢复模式的附加模式,允许执行高性能的大容量复制操作。通过使用最小方式记录大多数大容量操作,减少日志空间使用量。
工作丢失的风险:如果在最新日志备份后发生日志损坏或执行大容量日志记录操作,则必须重做自该上次备份之后所做的更改,否则不丢失任何工作。
能否恢复到时点:可以恢复到任何备份的结尾。不支持时点恢复。
切换到该模式的必要性:对于某些大规模大容量操作(如大容量导入或索引创建),暂时切换到大容量日志恢复模式可提高性能并减少日志空间使用量。仍需要日志备份。
何时使用大容量日志恢复模式:仅在运行大规模大容量操作期间以及在不需要数据库的时点恢复时使用该模式。
三、修改当前数据库恢复模式
--简单恢复模型: USE master; ALTER DATABASE dbname SET RECOVERY SIMPLE --完整恢复模型: USE master; ALTER DATABASE dbname SET RECOVERY FULL --批量日志恢复模型: USE master; ALTER DATABASE dbname SET RECOVERY BULK_LOGGED
发表在 SQL Server
评论关闭