sqlldr导入数据不全（sqlldr导入数据后要重建索引吗）



首先在sqlserver的查询分析器中查看特定数据库被阻塞的进程
select * from sysprocesses where dbid in (select dbid from sysdatabases where name=’ BugTracer’) and blocked>0
然后查看阻塞超时设置:SELECT @@LOCK_TIMEOUT
再次根据阻塞的进程ID查看阻塞语句:dbcc inputbuffer(108)
上面的108就是阻塞进程的ID。根据发现的语句可以用来分析是程序代码的哪部分造成了这个死锁，从而得以解决。
如果事情紧急，可以立即杀死阻塞进程，从而终结死锁的情况
kill 108

删除并重建索引
  用DROP INDEX和CREATE INDEX或ALTER TABLE来删除并重建索引有些缺陷包括在删除重建期间索引会消失。在索引删除重建时，对于查询它不再可用，查询性能也许会受到明显的影响，直到重建索引为止。另一个潜在的缺陷是当都请求索引的时候会引起阻塞，直到重建索引为止。通过其他的处理也能解决阻塞，就是索引被使用的时候不删除索引。另一个主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引时会引起非聚集索引重建两次。删除聚集索引时非聚集索引的行指针会指向数据堆，聚集索引重建时非聚集索引的行指针又会指回聚集索引的行位置。
  删除并重建索引的确有一个好处就是通过重新排序索引页，使索引页紧凑并删除不需要的索引页来完全重建索引。你也许需要考虑那些内部和外部碎片都很高的情况下才使用，以使那些索引回到它们应该在的位置。
 使用DROP_EXISTING子句重建索引
  为了避免在重建聚集索引时表上的非聚集索引重建两次，可以使用带DROP_EXISTING子句的CREATE INDEX语句。这个子句会保留聚集索引键值，以避免非聚集索引重建两次。和删除并重建索引一样，该方法也可能会引起阻塞和索引消失的问题。该方法的另一个缺陷是也强迫你去分别发现和修复表上的每一个索引。
  除了和上一个方法一样的好处之外，该方法的好处是不必重建非聚集索引两次。这样可以对那些带约束的索引提供正确的索引定义以符合约束的要求。
 执行DBCC DBREINDEX
  DBCC DBREINDEX类似于第二种方法，但它物理地重建索引，允许SQLServer给索引分配新页来减少内部和外部碎片。DBCC DBREINDEX也能动态的重建带约束的索引，不像第二种方法。
  DBCC DBREINDEX的缺陷是会遇到或引起阻塞问题。DBCC DBREINDEX是作为一个事务来运行的，所以如果在完成之前中断了，那么你会丢失所有已经执行过的碎片。
 执行DBCC INDEXDEFRAG
  DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引键的逻辑顺序，通过重新整理索引里存在的叶页来减少外部碎片，通过压缩索引页里的行然后删除那些由此产生的不需要的页来减少内部碎片。它不会遇到阻塞问题但它的结果没有其他几个方法彻底。这是因为DBCC INDEXDEFRAG跳过了锁定的页且不使用任何新页来重新排序索引。如果索引的碎片数量大的话你也许会发现DBCC INDEXDEFRAG比重建索引花费的时间更长。DBCC INDEXDEFRAG比其他方法的确有好处的是在其他过程访问索引时也能进行碎片整理，不会引起其他方法的阻塞问题。

非聚集不唯一索引

唯一非聚集索引

主健重建

查看哪些表占用了比较大的磁盘空间

增加输出查询的IP地址，如果没有退出，可以定位是谁做什么？

增加输出查询的IP地址，如果没有退出，可以定位是谁做什么？

使用性能监视器找出硬件瓶颈
SQLServer硬件性能监控列表
操作系统性能监控列表
SQLServer2000配置性能监控列表
数据库配置设置性能监控列表
索引性能监控列表
应用程序和T-SQL性能监控列表
SQLServer数据库作业性能监控列表
使用Profiler找出低效的查询
怎样最好的实现SQLServer性能监控

注意：通过索引的使用情况来分析系统设计的不合理性

http://www.zzvips.com/article/44216.html

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/sjkxydsj/22860.html