GVKun编程网logo

sql-server – 担心重组或重建索引的DBA可能导致数据丢失?

10

在这里,我们将给大家分享关于sql-server–担心重组或重建索引的DBA可能导致数据丢失?的知识,同时也会涉及到如何更有效地MySQLV5.1发现严重BUG可能导致数据丢失、SCOOPENSERV

在这里,我们将给大家分享关于sql-server – 担心重组或重建索引的DBA可能导致数据丢失?的知识,同时也会涉及到如何更有效地MySQL V5.1发现严重BUG 可能导致数据丢失、SCO OPENSERVER磁盘坏道,导致数据丢失,后数据恢复成功、SQL SERVER 2008 R2 重建索引的方法、sql server 日志文件清理 与 重建索引的内容。

本文目录一览:

sql-server – 担心重组或重建索引的DBA可能导致数据丢失?

sql-server – 担心重组或重建索引的DBA可能导致数据丢失?

我们有一些索引碎片的数据库是> 95%.最好的我可以告诉索引从未重建过少重组.多年.

(公平地说,这些表似乎确实启用了自动更新的统计数据.另外,在公平性方面,他对备份很勤奋:每天完整和每小时trx日志.)

当我问起时,DBA说他不愿重建或重组索引.当我问为什么时,他无法真正表达出来.最终他说他担心潜在的数据丢失.例如,我们的Great Plains Dynamics会计应用程序使用了其中一个数据库,他似乎非常担心这一点.

我不是DBA,但从我所读到的,他的焦虑似乎……我很难理解.

我不确定下一步该做什么.建议我该怎么办?

解决方法

重建数据库索引不应导致任何数据丢失.但是,由于重建的索引在重建完成之前通常无法使用,因此可能会导致性能显着下降.因此,应该在受影响的系统闲置时的非工作时间内完成.

偏执狂是DBA中的一件好事 – 如果他们担心数据丢失,我会让他们对备份进行适当的测试(将它们恢复到一个单独的系统并确保数据全部存在),如果他们是仍然担心在重建索引之前执行完整备份是一个合理的预防措施.

MySQL V5.1发现严重BUG 可能导致数据丢失

MySQL V5.1发现严重BUG 可能导致数据丢失

Sun在上周发布了MySQL数据库软件5.1版,之后他们称包括在新特性在内,该版本存在很多bug需要进行修复。据MySQL创始人Michael  Wideniu在blog中称,已经发现的bug问题很严重,可能会导致崩溃甚至数据丢失,而这个版本的bug不仅在就的功能上出现,新的特性也存在bug。

SCO OPENSERVER磁盘坏道,导致数据丢失,后数据恢复成功

SCO OPENSERVER磁盘坏道,导致数据丢失,后数据恢复成功

[申明]
    转载请保留原作网站: [url]http://www.sjhf.net[/url] 关键字[ SCO数据恢复]
    40G,IDE硬盘,存储重要INFORMIX数据库,出现坏道后无法启动系统,挂载在其他SCO系统上,无法识别。
    成功镜像原盘后分析,主分区表(partition)遇坏道,无法读取。片表(DIVVY)正常,读取用户主要数据区后分析,文件系统为HTFS,超级块损坏。
    分析结构后得到其文件系统参数,据此参数读取主节点表,部分节点损坏,费力分析后修复。
    根据重新生成的文件系统读取文件,成功读取所有INFORMIX数据库

SQL SERVER 2008 R2 重建索引的方法

SQL SERVER 2008 R2 重建索引的方法

参考sys.dm_db_index_physical_stats

检查索引碎片情况

1.SELECT
2.OBJECT_NAME(object_id) as objectname,
3.object_id AS objectid,
4.index_id AS indexid,
5.partition_number AS partitionnum,
6.avg_fragmentation_in_percent AS fra
7.FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, ‘LIMITED'')
8.WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;
9. 
10.使用脚本中的 sys.dm_db_index_physical_stats 重新生成或重新组织索引 (来源于联机帮助)
11. 
12.SET NOCOUNT ON;
13.DECLARE @objectid int;
14.DECLARE @indexid int;
15.DECLARE @partitioncount bigint;
16.DECLARE @schemaname nvarchar(130);
17.DECLARE @objectname nvarchar(130);
18.DECLARE @indexname nvarchar(130);
19.DECLARE @partitionnum bigint;
20.DECLARE @partitions bigint;
21.DECLARE @frag float;
22.DECLARE @command nvarchar(4000);
23.– Conditionally select tables and indexes from the sys.dm_db_index_physical_stats function
24.– and convert object and index IDs to names.
25.SELECT
26.object_id AS objectid,
27.index_id AS indexid,
28.partition_number AS partitionnum,
29.avg_fragmentation_in_percent AS frag
30.INTO #work_to_do
31.FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, ‘LIMITED'')
32.WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0;
33.– Declare the cursor for the list of partitions to be processed.
34.DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do;
35.– Open the cursor.
36.OPEN partitions;
37.– Loop through the partitions.
38.WHILE (1=1)
39.BEGIN;
40.FETCH NEXT
41.FROM partitions
42.INTO @objectid, @indexid, @partitionnum, @frag;
43.IF @@FETCH_STATUS < 0 BREAK;
44.SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name)
45.FROM sys.objects AS o
46.JOIN sys.schemas as s ON s.schema_id = o.schema_id
47.WHERE o.object_id = @objectid;
48.SELECT @indexname = QUOTENAME(name)
49.FROM sys.indexes
50.WHERE object_id = @objectid AND index_id = @indexid;
51.SELECT @partitioncount = count (*)
52.FROM sys.partitions
53.WHERE object_id = @objectid AND index_id = @indexid;
54.– 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding.
55.IF @frag < 30.0
56.SET @command = N‘ALTER INDEX ‘ + @indexname + N‘ ON ‘ + @schemaname + N‘.'' + @objectname + N‘ REORGANIZE'';
57.IF @frag >= 30.0
58.SET @command = N‘ALTER INDEX ‘ + @indexname + N‘ ON ‘ + @schemaname + N‘.'' + @objectname + N‘ REBUILD'';
59.IF @partitioncount > 1
60.SET @command = @command + N‘ PARTITION='' + CAST(@partitionnum AS nvarchar(10));
61.EXEC (@command);
62.PRINT N‘Executed: ‘ + @command;
63.END;
64.– Close and deallocate the cursor.
65.CLOSE partitions;
66.DEALLOCATE partitions;
67.– Drop the temporary table.
68.DROP TABLE #work_to_do;
69.GO
您可能感兴趣的文章:
  • sqlserver索引的原理及索引建立的注意事项小结
  • SQL Server 索引介绍
  • SQL Server 聚集索引和非聚集索引的区别分析
  • SQLSERVER全文目录全文索引的使用方法和区别讲解
  • SQLSERVER 创建索引实现代码
  • SQLSERVER聚集索引和主键(Primary Key)的误区认识
  • sqlserver 索引的一些总结
  • SQL Server全文索引服务
  • 提升SQL Server速度 整理索引碎片
  • SqlServer索引的原理与应用详解

sql server 日志文件清理 与 重建索引

sql server 日志文件清理 与 重建索引

可以直接使用数据库中的“维护计划”,通过维护计划向导来指定维护任务。如下图所示,通常我会新建如下任务:

 

有或者使用脚本定时处理,如下所示:

--操作前请先备份数据库
--日志收缩
USE [master]
GO
ALTER DATABASE EYDAYYLS SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE EYDAYYLS SET RECOVERY SIMPLE
GO
USE EYDAYYLS
GO
DBCC SHRINKFILE (N''EYBaby6_Log'' , 11, TRUNCATEONLY) 
GO
--USE [master]
--GO
--ALTER DATABASE EYDAYYLS SET RECOVERY FULL WITH NO_WAIT
--GO
--ALTER DATABASE EYDAYYLS SET RECOVERY FULL
--GO


--重建索引
use EYDAYYLS  --需要维护的数据库

 go
 declare @tablename varchar(100)
 declare  test_cur cursor for
 select object_name(id) from syscolumns 
where status=128
 open test_cur
 fetch test_cur into @tablename
 while @@fetch_status=0
 begin   
   DBCC CHECKIDENT (@tablename, RESEED)   
   fetch test_cur into @tablename
 end
 close test_cur
 deallocate test_cur
 go


declare @tablename varchar(100)
declare  test_cur cursor for
select object_name(id) from sysobjects 
where type =''U''
open test_cur
fetch test_cur into @tablename
while @@fetch_status=0
begin   
   DBCC DBREINDEX(@tablename)
   fetch test_cur into @tablename
end
close test_cur
deallocate test_cur
go

 

关于sql-server – 担心重组或重建索引的DBA可能导致数据丢失?的问题我们已经讲解完毕,感谢您的阅读,如果还想了解更多关于MySQL V5.1发现严重BUG 可能导致数据丢失、SCO OPENSERVER磁盘坏道,导致数据丢失,后数据恢复成功、SQL SERVER 2008 R2 重建索引的方法、sql server 日志文件清理 与 重建索引等相关内容,可以在本站寻找。

本文标签: