标签云
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,768)
- DB2 (22)
- MySQL (77)
- Oracle (1,609)
- 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备份恢复 (591)
- 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-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- 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报错
月归档:四月 2011
sql server中查看对象
1、查询所有数据库
select * from sys.databases;
2、查询对象
select * from sysobjects;
3、复制表结构和数据
SELECT * INTO t_1 FROM master.dbo.spt_monitor;
4、查询视图
SELECT * FROM sys.views;
5、查询列
select * from sys.columns;
6、查询索引
select * from sys.indexes;
发表在 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
评论关闭
INNODB参数的含义
innodb_data_home_dir | 这是InnoDB表的目录共用设置。如果没有在 my.cnf 进行设置,InnoDB 将使用MySQL的datadir目录为缺省目录。如果设定一个空字串,可以innodb_data_file_path中设定绝对路径。 |
innodb_data_file_path | 单独指定数据文件的路径与大小。数据文件的完整路径由 innodb_data_home_dir 与这里所设定值的组合。 文件大小以 MB 单位指定。因此在文件大小指定后必有“M”。 InnoDB 也支持缩写“G”, 1G = 1024M。从 3.23.44 开始,在那些支持大文件的操作系统上可以设置数据文件大小大于 4 GB。而在另一些操作系统上数据文件必须小于 2 GB。数据文件大小总和至少要达到 10 MB。在 MySQL-3.23 中这个参数必须在 my.cnf 中明确指定。在 MySQL-4.0.2 以及更新版本中则不需如此,系统会默认在 MySQL 的datadir目录下创建一个 16 MB 自扩充(auto-extending)的数据文件ibdata1。你同样可以使用一个 原生磁盘分区(RAW raw disk partitions(raw devices)) 作为数据文件 |
innodb_mirrored_log_groups | 为了保护数据而设置的日志文件组的拷贝数目,默认设置为 1。在my.cnf 中以数字格式设置。 |
innodb_log_group_home_dir | InnoDB 日志文件的路径。必须与
innodb_log_arch_dir设置相同值。 如果没有明确指定将默认在 MySQL 的datadir目录下建立两个 5 MB 大小的 ib_logfile… 文件。 |
innodb_log_files_in_group | 日志组中的日志文件数目。InnoDB 以环型方式(circular fashion)写入文件。数值 3 被推荐使用。在 my.cnf 中以数字格式设置。 |
innodb_log_file_size | 日志组中的每个日志文件的大小(单位 MB)。如果 n 是日志组中日志文件的数目,那么理想的数值为 1M 至下面设置的缓冲池(buffer pool)大小的 1/n。较大的值,可以减少刷新缓冲池的次数,从而减少磁盘 I/O。但是大的日志文件意味着在崩溃时需要更长的时间来恢复数据。 日志文件总和必须小于 2 GB,3.23.55 和 4.0.9 以上为小于 4 GB。在my.cnf 中以数字格式设置。 |
innodb_log_buffer_size | InnoDB 将日志写入日志磁盘文件前的缓冲大小。理想值为 1M 至 8M。大的日志缓冲允许事务运行时不需要将日志保存入磁盘而只到事务被提交(commit)。 因此,如果有大的事务处理,设置大的日志缓冲可以减少磁盘I/O。 在 my.cnf 中以数字格式设置。 |
innodb_flush_log_at_trx_commit | 通常设置为 1,意味着在事务提交前日志已被写入磁盘, 事务可以运行更长以及服务崩溃后的修复能力。如果你愿意减弱这个安全,或你运行的是比较小的事务处理,可以将它设置为 0 ,以减少写日志文件的磁盘 I/O。这个选项默认设置为 0。 |
innodb_log_arch_dir | The directory where fully written log files would be archived if we used log archiving. 这里设置的参数必须与innodb_log_group_home_dir相同。 从 4.0.6 开始,可以忽略这个参数。 |
innodb_log_archive | 这个值通常设为 0。 既然从备份中恢复(recovery)适合于 MySQL 使用它自己的 log files,因而通常不再需要 archive InnoDB log files。这个选项默认设置为 0。 |
innodb_buffer_pool_size | InnoDB 用来高速缓冲数据和索引内存缓冲大小。 更大的设置可以使访问数据时减少磁盘 I/O。在一个专用的数据库服务器上可以将它设置为物理内存的 80 %。 不要将它设置太大,因为物理内存的使用竞争可能会影响操作系统的页面调用。在 my.cnf 中以数字格式设置。 |
innodb_additional_mem_pool_size | InnoDB 用来存储数据字典(data dictionary)信息和其它内部数据结构(internal data structures)的存储器组合(memory pool)大小。理想的值为 2M,如果有更多的表你就需要在这里重新分配。如果 InnoDB 用尽这个池中的所有内存,它将从操作系统中分配内存,并将错误信息写入 MySQL 的错误日志中。在 my.cnf 中以数字格式设置。 |
innodb_file_io_threads | InnoDB 中的文件 I/O 线程。 通常设置为 4,但是在 Windows 下可以设定一个更大的值以提高磁盘 I/O。在 my.cnf 中以数字格式设置。 |
innodb_lock_wait_timeout | 在回滚(rooled back)之前,InnoDB 事务将等待超时的时间(单位 秒)。InnoDB 会自动检查自身在锁定表与事务回滚时的事务死锁。如果使用LOCK TABLES命令,或在同一个事务中使用其它事务安全型表处理器(transaction safe table handlers than InnoDB),那么可能会发生一个 InnoDB 无法注意到的死锁。在这种情况下超时将用来解决这个问题。这个参数的默认值为 50 秒。在 my.cnf 中以数字格式设置。 |
innodb_flush_method | 这个参数仅仅与 Unix 相关。这个参数默认值为fdatasync。 另一个设置项为O_DSYNC
。这仅仅影响日志文件的转储,在 Unix 下以fsync转储数据。InnoDB 版本从 3.23.40b 开始,在 Unix 下指定fdatasync 为使用fsync方式、指定O_DSYNC为使用O_SYNC方式。由于这在某些 Unix 环境下还有些问题所以在 ‘data’ versions 并没有被使用。 |
innodb_force_recovery | 警告:此参数只能在你希望从一个被损坏的数据库中转储(dump)数据的紧急情况下使用! 可能设置的值范围为 1 – 6。查看下面的章节 ‘Forcing recovery’ 以了解这个参数的具体含义。参数设置大于 0 的值代表着 InnoDB 防止用户修改数据的安全度。从 3.23.44 开始,这个参数可用。在 my.cnf 中以数字格式设置。 |
innodb_fast_shutdown | InnoDB 缺少在关闭之前清空插入缓冲。这个操作可能需要几分钟,在极端的情况下可以需要几个小时。如果这个参数据设置为 1 ,InnoDB 将跳过这个过程而直接关闭。从 3.23.44 和 4.0.1 开始,此参数可用。从 3.23.50 开始,此参数的默认值为 1。 |
innodb_thread_concurrency | InnoDB 会试图将 InnoDB 服务的使用的操作系统进程小于或等于这里所设定的数值。此参数默认值为 8。如果计算机系统性能较低或innodb_monitor显示有很多线程等侍信号,应该将这个值设小一点。如果你的计算机系统有很我的处理器与磁盘系统,则可以将这个值设高一点以充分利用你的系统资源。建议设值为处理器数目+ 磁盘数目。 从 3.23.44 和 4.0.1 开始,此参数可用。在 my.cnf 中以数字格式设置。 |
发表在 MySQL
评论关闭