fzzf

黑客X档案青野志狼有一篇文章>。文章写到了在知道sql服务器的SA用户名弱密码后，而服务器去掉了SA的xp_cmdshell权限的情况下，如何通过SQL命令恢复SA的xp_cmdshell权限来进行入侵。这样入侵(详细请看原文)的前提是服务器的xplog70.dll没有被删除或改名，这一点青野志狼也谈到了，但是他没有写在xplog70.dll被删掉或改名的情况下的入侵方法。这里就把我曾经在这样情况

一. 为什么要引入锁多个用户同时对数据库的并发操作时会带来以下数据不一致的问题:丢失更新A,B两个用户读同一数据并进行修改,其中一个用户的修改结果破坏了另一个修改的结果,比如订票系统脏读A用户修改了数据,随后B用户又读出该数据,但A用户因为某些原因取消了对数据的修改,数据恢复原值,此时B得到的数据就与数据库内的数据产生了不一致不可重复读A用户读取数据,随后B用户读出该数据并修改,此时A用户再读取数

--语 句 功 能--数据操作SELECT --从数据库表中检索数据行和列INSERT --向数据库表添加新数据行DELETE --从数据库表中删除数据行UPDATE --更新数据库表中的数据--数据定义CREATE TABLE --创建一个数据库表DROP TABLE --从数据库中删除表ALTER TABLE --修改数据库表结构CREATE VIEW --创建一个视图DROP VIEW --

人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中(如联机事务处理OLTP或决策支持系统DSS)中表现得尤为明显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充分的连接条件和不可优化的where子句。在对它们进行适当的优化后，其运行速度有了明显的提高!下面我将从这三个方面分

实现小数据量和海量数据的通用分页显示存储过程 　　建立一个 Web 应用，分页浏览功能必不可少。这个问题是数据库处理中十分常见的问题。经典的数据分页方法是:ADO 纪录集分页法，也就是利用ADO自带的分页功能（利用游标）来实现分页。但这种分页方法仅适用于较小数据量的情形，因为游标本身有缺点：游标是存放在内存中，很费内存。游标一建立，就将相关的记录锁住，直到取消游标。游标提供了对特定集合中逐行扫描的

聚集索引的重要性和如何选择聚集索引 　　在上一节的标题中，笔者写的是：实现小数据量和海量数据的通用分页显示存储过程。这是因为在将本存储过程应用于“办公自动化”系统的实践中时，笔者发现这第三种存储过程在小数据量的情况下，有如下现象： 1、分页速度一般维持在1秒和3秒之间。 2、在查询最后一页时，速度一般为5秒至8秒，哪怕分页总数只有3页或30万页。 　　虽然在超大容量情况下，这个分页的实现过程是很快

改善SQL语句 　　很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如： select * from table1 where name=zhangsan and tID > 10000和执行:select * from table1 where tID > 10000 and name=zhangsan　　一

一、深入浅出理解索引结构 　　实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别： 　　其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自

SQL Server应用程序中的高级SQL注入作者：Chris Anley[chris@ngssoftware.com]An NGSSoftware Insight Security Research(NISR) Publication翻译：青野志狼（panderlang）来源：狼族在线(http://www.panderlang.com/)第一次翻译，水平有限，难免有错，请不吝指正。转载请保留信

我的BLOG里有一篇文章介绍了关于SQL注入的基本原理和一些方法。最让人感兴趣的也许就是前面介绍的利用扩展存储过程xp_cmdshell来运行操作系统的控制台命令。这种方法也非常的简单，只需使用下面的SQL语句：EXEC master.dbo.xp_cmdshell dir c:/但是越来越多的数据库管理员已经意识到这个扩展存储过程的潜在危险，他们可能会将该存储过程的动态链接库xplog70.

原地址:http://blog.youkuaiyun.com/wslz2001/archive/2005/12/30/566341.aspx人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的