K/3数据库日志文件过大分析及解决方案
本期概述
●本文档适用于金蝶k/3（使用SQL Server 2000、SQL Server 2005作为数据库）。
●本文档主要阐述了，在K3备份过程中,遇到:”日志文件过大,系统无法完成备份”
的问题分析及解决方案。通过对本文档的学习，能够掌握这种问题产生的原因以及解决方法。
版本信息
●2009年6月10日 V11.0 编写人：周素帆
●2009年6月日 V11.0 修改人：
版权信息
●本文件使用须知
著作权人保留本文件的内容的解释权，并且仅将本文件内容提供给阁下个人使用。对于内容中所含的版权和其他所有权声明，您应予以尊重并在其副本中予以保留。您不得以任何方式修改、复制、公开展示、公布或分发这些内容或者以其他方式把它们用于任何公开或商业目的。任何未经授权的使用都可能构成对版权、商标和其他法律权利的侵犯。如果您不接受或违反上述约定，您使用本文件的授权将自动终止，同时您应立即销毁任何已下载或打印好的本文件内容。
著作权人对本文件内容可用性不附加任何形式的保证，也不保证本文件内容的绝对准确性和绝对完整性。本文件中介绍的产品、技术、方案和配置等仅供您参考，且它们可能会随时变更，恕不另行通知。本文件中的内容也可能已经过期，著作权人不承诺更新它们。如需得到最新的技术信息和服务，您可向当地的金蝶业务联系人和合作伙伴进行咨询。
著作权声明著作权所有 2009 金蝶软件（中国）有限公司。
所有权利均予保留。
目录
第一章报错现象及分析 (3)
一、报错现象 (3)
二、问题分析 (3)
三、关于日志文件 (4)
第二章解决方案 (4)
一、SQL 2000 (4)
1、执行数据库分离附加 (4)
2、数据库收缩操作 (12)
二、SQL 2005 (16)
1、分离附加数据库 (16)
2、收缩数据库 (19)
第一章报错现象及分析
一、报错现象
案例一、在进行帐套备份的时候提示以下错误，如图1.1所示：
图1.1
案例二、在进行单据录入的时候提示以下错误，如图1.2所示：
图1.2
点击确定后出现如下提示，如图1.3所示：
图1.3
后弹出单句录入界面为不可录入状态，点新增后仍然继续弹出错误提示。
二、问题分析
问题的原因可能主要是由于统计，排序等操作做的太多，太频繁。导致账套实体的事务日志的增长已超过当前的限制太小所致。
如果客户数据库的LOG文件过大，也会导致客户端运行速度变慢，严重时连一个客户端都进不去。产生性能问题。
三、关于日志文件
主要数据文件是数据库的起点，指向数据库中文件的其它部分。每个数据库都有一个主要数据文件。主要数据文件的推荐文件扩展名是 .mdf。
日志文件包含恢复数据库所需的所有日志信息。每个数据库必须至少有一个日志文件，但可以不止一个。日志文件的推荐文件扩展名是 .ldf。
日志文件增长：可以按百分比或实际大小指定增长速度。日志文件容量设置：可以指定文件增长的最大值或不受限。
在SQL Server 中，如果设置了自动增长功能，事务日志文件将会自动扩展。
一般情况下，在能够容纳两次事务日志截断之间发生的最大数量的事务时，事务日志的大小是稳定的，事务日志截断由检查点或者事务日志备份触发。
然而，在某些情况下，事务日志可能会变得非常大，以致用尽空间或变满。通常，在事务日志文件占尽可用磁盘空间且不能再扩展时，除了出现此错误消息之外，SQL Server 还可能因为缺少事务日志扩展空间而将数据库标记为SUSPECT。另外，事务日志扩展可能导致下列情形： 1）、非常大的事务日志文件。2）、事务可能会失败并可能开始回滚。 3）、事务可能会用很长时间才能完成。 4）、可能发生性能问题。 5）、可能发生阻塞现象。
分析事务日志扩展可能由于以下原因或情形而发生： 1）、未提交的事务 2）、非常大的事务 3）、操作：DBCC DBREINDEX 和CREATE INDEX 4）、在从事务日志备份还原时 5）、客户端应用程序不处理所有结果 6）、查询在事务日志完成扩展之前超时，您收到假的“Log Full”错误消息 7）、未复制的事务
第二章解决方案
一、SQL 2000
1、执行数据库分离附加。
概述：
该方法有一定的风险性，因为SQL SERVER的日志文件不是即时写入数据库主文件的，如过处理不当，可能会造成数据的损失。
1: 分离数据库企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
2：附加数据库企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
此法生成新的LOG，大小只有500多K。
注意：
因为日志大到一定的程度，就无法进行备份，而该方法又存在一定的风险。所以如果对数据要求特别高的话建议可以先收缩日志文件，进行完全备份。之后再进行分离附加数据库的操作。
详细操作步骤：
首先点击开始菜单→找到所有程序→金蝶k3→金蝶k3服务器配置工具→帐套管理，确
定帐套对应的数据库实体文件是那一个。并且记录下该数据库实体名称。如下图2.1所示：
图2.1
其次点击开始菜单→找到所有程序→MICROSOFT SQL SERVER →企业管理器.详细见图2.2
图2.2
打开到企业管理器界面，展开到数据库:如图2.3
图2.3
第一步，将问题账套实体进行数据分离。
在数据库列表中,可以看到K3对应的数据库实体,选中该数据库实体,点右键:选择属性。点击数据文件:记住位置中的文件路径(该文件夹是我们数据库文件所保存的位置.)如图2.4
图2.4
再关掉属性框,回到该数据库实体中. 进入SQL SERVER企业管理器进行分离。SQL SERVER 企业管理器-》Micro SQL Servers-》SQL Server组-》（local） Windows NT-》数据库-》帐套号-》所有任务-》分离数据库。如图2.5.
图2.5
(注意该操作要保证没有客户端登陆的情况下做,否则,客户端后面做的数据,将无法保存.)
如果数据库状态中显示:“使用本数据库的连接”不为0,则点旁边的“清除”。如图2.6
图2.6
然后点确定：此时，数据库列表中将没有了该数据库实体(图2.7)。
图2.7
打开此前记住的数据库文件所在文件夹：
第二步，删除问题账套实体的数据库日志文件。
找到该数据库实体名称所对应的日志文件：扩展名为：.ldf或_log.ldf,如图2.8：把该日志文件剪切到其他文件夹（或者删除）。因为稍后会生成一个新的日志文件，一般约500k 左右。注册帐套的时候需要使用到日志文件，如果剪切到其他的文件夹下了，以后还可以找回来。如果客户对数据要求非常高。不建议删除。
图2.8
确保数据库数据文件（扩展名为：MDF）与日志文件（扩展名为：LDF）不在同一个文件夹下。
第三步，将问题帐套数据实体重新附加回SQL数据库中。
步骤：回到企业管理器（控制台）上，到数据库项上点右键→所有任务→附加数据库
图2.9 出现界面如图所示：
图2.10 选择数据文件（扩展名为.MDF）
图2.11 确定后如下图所示：
图2.12 点确定：出现下图所示提示：
图2.13
继续确定：
最后，数据库正常附加。
图2.14
此时可以看到新的日志文件只有504k.。
图2.15
第四步，将问题帐套数据实体重新注册。
最后您需要进入帐套管理，把帐套注册回来。就可以了。先运行反注册帐套。如下图：
图2.16
之后选择注册帐套。
图2.17
注意选择身份验证方式：
图2.18
2、数据库收缩操作。
概述：
1、修改故障模型方式在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
2、重新启动数据库服务。
3、收缩日志文件企业管理器->数据库实体->所有任务->收缩数据库->收缩文件。
详细操作步骤：
首先点击开始菜单→找到所有程序→金蝶k3→金蝶k3服务器配置工具→帐套管理，确定帐套对应的数据库实体文件是那一个。并且记录下该数据库实体名称。如下图2.19所示：
图2.19
其次点击开始菜单→找到所有程序→MICROSOFT SQL SERVER →企业管理器.详细见图2.20
图2.20
打开到企业管理器界面，展开到数据库:如图2.21
图2.21
第一步，修改问题账套实体故障还原模式。
在对应的数据库实体上点右键->属性->选项->故障还原->模型->选择:简单模型。如图2.22所示。
图2.22
第二步，重新启动数据库服务。
右健单击【我的电脑】，选择管理->服务和应用程序->服务。在列表中选择MSSQLSERVER服务。如图2.23所示。
图2.23
第三步，收缩数据库日志文件。
在数据库的企业管理器中，右击该数据库实体选择所有任务中收缩数据库，如图 2.24所示。
图2.24
选择文件打开如下界面，选择日志文件，然后输入收缩到的数值。确定。如图2.25所示：
图2.25
分离附加日志文件和收缩日志文件效果都是一样的，都起到了减小日志文件的作用。
做完以上操作之后，您就可以正常的使用k3了。
如果以后,不想要它变大。有以下3种方法。
1）、在数据库上点右键->属性->选项->故障恢复→模型->选择->简单模型。也可以使用命令：alter database 数据库名 set recovery simple
2）、企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩"
3）、右建数据库属性窗口--故障还原模型--设为大容量日志记录
二、SQL 2005
1、分离附加数据库
首先点击开始菜单→找到所有程序→金蝶k3→金蝶k3服务器配置工具→帐套管理，确定帐套对应的数据库实体文件是那一个。并且记录下该数据库实体名称。
其次点击开始菜单→找到所有程序→MICROSOFT SQL SERVER 2005→SQL Server Managerment Studio 如下图3.1所示.
图3.1
输入用户名密码，登陆。展开到数据库。如图3.2所示
图3.2
第一步，将问题账套实体进行数据分离。
在数据库列表中,可以看到K3对应的数据库实体,选中该数据库实体,点右键:选择属性。点击文件:记住位置中的文件路径(该文件夹是我们数据库文件所保存的位置.)如图3.3所示
图3.3
再关掉属性框,回到该数据库实体中.
进入SQL SERVER Managerment Studio中进行分离。数据库->任务->分离。如图3.4所示
图3.4
弹出如图3.5所示界面，点确定后，会提示分离成功。
图3.5
打开此前记住的数据库文件所在文件夹：
第二步，删除问题账套实体的数据库日志文件。
找到该数据库实体名称所对应的日志文件：扩展名为：.ldf或_log.ldf,如图2.8：把该日志文件剪切到其他文件夹（或者删除）。因为稍后会生成一个新的日志文件。注册帐套的时候需要使用到日志文件，如果剪切到其他的文件夹下了，以后还可以找回来。如果客户对数据要求非常高。不建议删除。
确保数据库数据文件（扩展名为：MDF）与日志文件（扩展名为：LDF）不在同一个文件夹下。
第三步，将问题帐套数据实体重新附加回SQL数据库中。
步骤：回到Managerment Studio（控制台）上，到数据库上点右键 附加。在弹出的界面，单击添加，找到对应的数据库实体文件。如图3.6所示，后单击确定。
图3.5
此时可以看到新的日志文件只有504k.。
2、收缩数据库
收缩数据库的步骤同2000中是一样的，详细请参考本文2.1.2。在此不做赘述。
先将数据进行备份（所有帐套）
1.在SQL企业管理器-locanl windows nt-数据库-账套号-属性-事务日志-最大文件大小选择“文件增长不受限制“
2.将问题账套实体进行数据分离
3.删除问题账套实体的数据库日志文件。
4.将问题账套数据实体重新附加回SQL数据库
5.用账套管理工具进行账套注册
基于MyCat 分布式数据库解决方案的学汇总 最近公司推荐了mycat分布式中间件解决数据库分布式方案，今天到mycat官网学了一翻 （https://www.doczj.com/doc/8511503421.html,），汇总下几个重点： 1、mycat是什么？ mycat是一个开源的分布式数据库系统,是一个实现了MySQL 协议的Server,前端用户可以把它看作是一个数据库代理,用MySQL 客户端工具和命令进行访问,后端可以用MySQL 原生(Native)协议访问数据库（不限于MYSQL数据库）, 其核心功能是分表分库,即将一个多表水平分割为N 个小表,存储在后端的数据库中。 以下是几种通俗的方式介绍MYCAT： 1）对于DBA 来讲: Mycat 就是MySQL Server,而Mycat 后面连接的MySQL Server,就好象是MySQL 的存储引擎,如InnoDB,MyISAM 等,因此,Mycat 本身并不存储数据,数据是在后端的MySQL 上存储的,因此数据可靠性以及事务等都是MySQL 保证的,简单的说,Mycat 就是MySQL 最佳伴侣,它在一定程度上让MySQL 拥有了能跟Oracle PK 的能力。 2）对于开发来讲:
Mycat 就是一个近似等于MySQL 的数据库服务器,你可以用连接MySQL 的方式去连接Mycat(除了端口不同,默认的Mycat 端口是8066 而非MySQL 的3306,因此需要在连接字符串上增加端口信息),大多数情况下,可以用你熟悉的对象映射框架使用Mycat,但建议对于分片表,尽量使用基础的SQL 语句,因为返样能达到最佳性能,特别是几千万甚至几百亿条记录的情况下。 3）对于架构师来讲： Mycat 是一个强大的数据库中间件,不仅仅可以用作读写分离、以及分表分库、容灾备份,而且可以用于多租户应用开发、平台基础设施、让你的架构具备很强的适应性和灵活性,借助于即将发布的Mycat 智能优化模块,系统的数据访问瓶颈和热点一目了然,根据返些统计分析数据,你可以自动或手工调整后端存储,将不同的表映射到不同存储引擎上,而整个应用的代码一行也不用改变。 2）双活部署 mycat、zk均采用双中心部署 3、常见的数据库切分优化方案 传统数据库存在着先天性的弊端,但是NoSQL 数据库又无法将其替今,NoSQL 只能作为传统数据的补充而不能将其
sql server日志文件总结及日志满的处理办法 交易日志（Transaction logs）是数据库结构中非常重要但又经常被忽略的部分。由于它并不像数据库中的schema那样活跃，因此很少有人关注交易日志。交易日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。对于任何每一个交易过程，交易日志都有非常全面的记录，根据这些记录可以将数据文件恢复成交易前的状态。从交易动作开始，交易日志就处于记录状态，交易过程中对数据库的任何操作都在记录范围，直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志以及一个数据文件。 出于性能上的考虑，SQL Server将用户的改动存入缓存中，这些改变会立即写入交易日志，但不会立即写入数据文件。交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件。当SQL Server重启后，它会查看日志中最新的标记点，并将这个标记点后面的交易记录抹去，因为这些交易记录并没有真正的将缓存中的数据写入数据文件。这可以防止那些中断的交易修改数据文件。 维护交易日志 因为很多人经常遗忘交易日志，因此它也会给系统带来一些问题。随着系统的不断运行，日志记录的内容会越来越多，日志文件的体积也会越来越大，最终导致可用磁盘空间不足。除非日常工作中经常对日志进行清理，否则日志文件最终会侵占分区内的全部可用空间。日志的默认配置为不限容量，如果以这种配置工作，它就会不断膨胀，最终也会占据全部可用空间。这两种情况都会导致数据库停止工作。 对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。备份过程会将日志中不再需要的部分截除。截除的方法是首先把旧记录标记为非活动状态，然后将新日志覆盖到旧日志的位置上，这样就可以防止交易日志的体积不断膨胀。如果无法对日志进行经常性的备份工作，最好将数据库设置为"简单恢复模式"。在这种模式下，系统会强制交易日志在每次记录标记点时，自动进行截除操作，以新日志覆盖旧日志。 截除过程发生在备份或将旧标记点标为非活动状态时，它使得旧的交易记录可以被覆盖，但这并不会减少交易日志实际占用的磁盘空间。就算不再使用日志，它依然会占据一定的空间。因此在维护时，还需要对交易日志进行压缩。压缩交易日志的方法是删除非活动记录，从而减少日志文件所占用的物理硬盘空间。 通过使用DBCC SHRINKDATABASE语句可以压缩当前数据库的交易日志文件，DBCC SHRINKFILE语句用来压缩指定的交易日志文件，另外也可以在数据库中激活自动压缩操作。当压缩日志时，首先会将旧记录标记为非活动状态，然后将带有非活动标记的记录彻底删除。根据所使用的压缩方式的不同，你可能不会立即看到结果。在理想情况下，压缩工作应该选在系统不是非常繁忙的时段进行，否则有可能影响数据库性能。 恢复数据库 交易记录备份可以用来将数据库恢复到某一指定状态，但交易记录备份本身不足以完成恢复数据库的任务，还需要备份的数据文件参与恢复工作。恢复数据库时，首先进行的是数据文件的恢复工作。在整个数据文件恢复完成前，不要将其设为完成状态，否则交易日志就不会被恢复。当数据文件恢复完成，系统会通过交易日志的备份将数据库恢复成用户希望的
SQL Server 数据库清除日志的方法 方法一： 1、打开查询分析器，输入命令 BACKUP LOG database_name WITH NO_LOG 2、再打开企业管理器--右键要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至xxm,这里会给出一个允许收缩到的最小m数,直接输入这个数,确定就可以了。 方法二： 设置检查点，自动截断日志 一般情况下，SQL数据库的收缩并不能很大程度上减小数据库大小，其主要作用是收缩日志大小，应当定期进行此操作以免数据库日志过大 1、设置数据库模式为简单模式：打开SQL企业管理器，在控制台根目录中依次点开Microsoft SQL Server-->SQL Server组-->双击打开你的服务器-->双击打开数据库目录-->选择你的数据库名称（如用户数据库cwbase1）-->然后点击右键选择属性-->选择选项-->在故障还原的模式中选择“简单”，然后按确定保存 2、在当前数据库上点右键，看所有任务中的收缩数据库，一般里面的默认设置不用调整，直接点确定 3、收缩数据库完成后，建议将您的数据库属性重新设置为标准模式，操作方法同第一点，因为日志在一些异常情况下往往是恢复数据库的重要依据 方法三：通过SQL收缩日志 把代码复制到查询分析器里，然后修改其中的3个参数(数据库名，日志文件名，和目标日志文件的大小)，运行即可 SET NOCOUNT ON DECLARE @LogicalFileNamesysname, @MaxMinutes INT, @NewSize INT USE tablename -- 要操作的数据库名 SELECT @LogicalFileName = 'tablename_log', -- 日志文件名 @MaxMinutes = 10, -- Limit on time allowed to wrap log. @NewSize = 1 -- 你想设定的日志文件的大小(M) -- Setup / initialize DECLARE @OriginalSizeint SELECT @OriginalSize = size FROM sysfiles WHERE name = @LogicalFileName SELECT 'Original Size of ' + db_name() + ' LOG is ' + CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB' FROM sysfiles WHERE name = @LogicalFileName CREATE TABLE DummyTrans (DummyColumn char (8000) not null) DECLARE @Counter INT,
服务器高并发解决方案 篇一：JAVA WEB高并发解决方案 java处理高并发高负载类网站中数据库的设计方法（java教程,java处理大量数据，java高负载数据）一：高并发高负载类网站关注点之数据库没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是的应用，数据库的响应是首先要解决的。 一般来说MySQL是最常用的，可能最初是一个mysql 主机，当数据增加到100万以上，那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。 Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。 以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，
切分到不同的数据库集群去。 全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。 每个cluster可以用m-m方式，或者m-m-slaves方式。这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysql cluster进去。 需要注意的是： 1、禁用全部auto_increment的字段 2、id需要采用通用的算法集中分配 3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。 4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，或者干脆自己做，因为php4中mysql的链接池经常出问题。 二：高并发高负载网站的系统架构之HTML静态化 其实大家都知道，效率最高、消耗最小的就是纯静态化 /shtml/XX07/的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实
××ERP项目实施解决方案 建立日期: 修改日期: 文控编号: UF_XX(机构代码)_XX(实施)_XXXX(PMP项目号)_XX(阶段)_XX(流水号)_M(为里程碑) 客户项目经理： 日期： 用友项目经理： 日期：
<说明：本方案基于用友XX产品系列软件，主要针对XX产品X版本，由于不同版本产品功能会有差异，当您使用XX产品其他版本时，敬请进行详细的测试和修订。> 文档控制 更改记录 查阅 分发
目录 第一章概述 (6) 第二章总体实施架构 (6) 2.1企业基本信息 (6) 2.2信息化总体目标 (7) 2.3ERP应用模块 (7) 2.4信息化总体流程 (9) 第三章关键基础设置 (9) 3.1关键业务参数 (9) 3.1.1 建账参数设置： (9) 3.1.2 总账参数设置： (10) 3.1.3 应收、应付系统参数设置： (10) 3.1.4 采购管理参数设置： (11) 3.1.5 销售管理参数设置： (11) 3.1.6 库存管理参数设置： (12) 3.1.7 存货核算参数设置： (12) 3.1.8 (13) 3.2权限设置（请参照《实施解决方案-岗位及权限设置（附）》） (13) 第四章销售业务流程设计 ......................................................................................... 错误!未定义书签。 4.1销售管理目标/关键需求 ................................................................................................. 错误!未定义书签。 4.2销售一级业务流程及说明............................................................................................... 错误!未定义书签。 4.3二级业务流程及说明........................................................................................................ 错误!未定义书签。 4.3.1 销售订货业务 .................................................................................................................. 错误!未定义书签。 4.3.2 销售发货业务 .................................................................................................................. 错误!未定义书签。 4.3.3 销售出库业务 .................................................................................................................. 错误!未定义书签。 4.3.4 业务X ................................................................................................................................. 错误!未定义书签。 4.4特殊业务处理说明............................................................................................................. 错误!未定义书签。 4.4.1 信用管理业务 .................................................................................................................. 错误!未定义书签。 4.4.2 XX业务............................................................................................................................... 错误!未定义书签。
Oracle数据库归档日志日常管理与建议 1.简介 近日，项目组偶有发生归档日志占满归档目录空间导致数据库hang住（无响应），导致系统不能正常应用的情况。针对此类问题，笔者从Oracle数据库归档模式、归档模式的优缺点、归档日志日常管理方法等各方面浅析并整理出归档日志日常管理与建议。请各项目组依据实际情况，规范管理归档日志，排查相关隐患，以保证系统的正常高效运营。 另外，对于已开启数据库归档模式的项目组，若数据库管理权限不在我方，可将相关归档管理建议与当地运维部门充分沟通，避免归档的不当管理引起事故。 2.数据库归档模式与归档日志 2.1数据库运行模式简介 Oracle数据库包括归档模式与非归档模式两种运行模式。 一般情况下Oracle数据库的联机重做日志会记录对数据库所做的所有的修改，如创建对象；插入、删除、更新对象；删除对象等，这些操作都会记录在联机重做日志里。Oracle 数据库至少要有2个联机重做日志组。当一个联机重做日志组被写满（假设为1）的时候，就会发生日志切换，这时联机重做日志组2（假设为2）成为当前使用的日志，当联机重做日志组2写满的时候，又会发生日志切换，去写联机重做日志组1，这样反复进行。 如果数据库处于非归档模式，联机日志在切换时就会被丢弃。而在归档模式下，当发生日志切换的时候，被切换的联机日志会被归档。 如当前在使用联机重做日志1，当1被写满时，发生日志切换，开始写联机重做日志2，这时联机重做日志1的内容会被拷贝到一个指定的目录下。这个目录为归档目录，这个过程称之为归档，拷贝的文件叫归档日志。 2.2归档模式优点与归档日志作用 数据库运行在归档模式时，后台进程ARCH会将联机日志的内容拷贝到归档目录生成归档日志。 当数据库出现介质失败时，使用数据文件备份，归档日志和重做日志可以完全恢复数据库。因此，开启归档模式及归档日志的益处与作用是非常明显的： 1.可以进行完全、不完全恢复。由于对数据库所做的全部改动都记录在日志文件中， 如果发生硬盘故障等导致数据文件丢失的故障，则可以利用物理备份和归档日志 完全恢复数据库，不会丢失任何数据。 2.可以进行联机热备。所谓联机热备，就是在数据库运行状态下，对数据库进行备 份，备份时用户对数据库的使用基本不受影响（不可避免的会对性能有负面影响）。 3.可以实施Data Guard。可以部署1个或多个备用数据库，从而最大限度地提供灾 难保护手段。
数据库的事务日志已满。若要查明无法重用日志中的空间的原因 ，请参阅sys.databases 中的log_reuse_wait_desc 列 一般不建议做第4，6两步 第4步不安全，有可能损坏数据库或丢失数据 第6步如果日志达到上限，则以后的数据库处理会失败，在清理日志后才能恢复. 1、清空日志 DBCC SHRINKFILE(库名_log，0) DUMP TRANSACTION 库名WITH NO_LOG 2、截断事务日志： 如果出现“未能在sysfiles 中找到文件库名_log'。 DBCC 执行完毕。如果DBCC 输出了错误信息，请与系统管理员联系。” 则使用这句SQL操作 BACKUP LOG 库名WITH NO_LOG DBCC SHRINKFILE(2，0) 3.收缩数据库文件(如果不压缩，数据库的文件不会减小 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 a、选择日志文件--收缩文件至，这里会给出一个允许收缩到的最小M数，确定就可以了 b、选择数据文件--收缩文件至，这里会给出一个允许收缩到的最小M数，，确定就可以了也可以用SQL语句来完成 --收缩数据库 DBCC SHRINKDA TABASE(库名) --收缩指定数据文件，1是文件号，可以通过这个语句查询到:select * from sysfiles DBCC SHRINKFILE(1) 4.为了最大化的缩小日志文件(如果是sql 7.0，这步只能在查询分析器中进行)
a.分离数据库: 企业管理器--服务器--数据库--右键--分离数据库 b.在我的电脑中删除LOG文件 c.附加数据库: 企业管理器--服务器--数据库--右键--附加数据库 此法将生成新的LOG，大小只有500多K 或用代码： 下面的示例分离pubs，然后将pubs 中的一个文件附加到当前服务器。a.分离 EXEC sp_detach_db @dbname = '库名' b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db @dbname = '库名'， @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\库名.mdf' 5.为了以后能自动收缩，做如下设置: 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩" --SQL语句设置方式: EXEC sp_dboption '库名'，'autoshrink'，'TRUE' 6.如果想以后不让它日志增长得太大 企业管理器--服务器--右键数据库--属性--事务日志 --将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式: alter database 库名modify file(name=逻辑文件名，maxsize=20)
数据库审计系统技术建议书
目次 1.综述 (1) 2.需求分析 (1) 2.1.内部人员面临的安全隐患 (2) 2.2.第三方维护人员的威胁 (2) 2.3.最高权限滥用风险 (2) 2.4.违规行为无法控制的风险 (2) 2.5.系统日志不能发现的安全隐患 (2) 2.6.系统崩溃带来审计结果的丢失 (3) 3.审计系统设计方案 (3) 3.1.设计思路和原则 (3) 3.2.系统设计原理 (4) 3.3.设计方案及系统配置 (14) 3.4.主要功能介绍 (5) 3.4.1.数据库审计........................ 错误!未定义书签。 3.4.2.网络运维审计 (9) 3.4.3.OA审计............................ 错误!未定义书签。 3.4.4.数据库响应时间及返回码的审计 (9) 3.4.5.业务系统三层关联 (9) 3.4.6.合规性规则和响应 (10) 3.4.7.审计报告输出 (12) 3.4.8.自身管理 (13) 3.4.9.系统安全性设计 (14) 3.5.负面影响评价 (16) 3.6.交换机性能影响评价 (17) 4.资质证书.......................... 错误!未定义书签。
1.综述 随着计算机和网络技术发展，信息系统的应用越来越广泛。数据库做为信息技术的核心和基础，承载着越来越多的关键业务系统，渐渐成为商业和公共安全中最具有战略性的资产，数据库的安全稳定运行也直接决定着业务系统能否正常使用。 围绕数据库的业务系统安全隐患如何得到有效解决，一直以来是IT治理人员和DBA们关注的焦点。做为资深信息安全厂商，结合多年的安全研究经验，提出如下解决思路： 管理层面：完善现有业务流程制度，明细人员职责和分工，规范内部员工的日常操作，严格监控第三方维护人员的操作。 技术层面：除了在业务网络部署相关的信息安全防护产品（如FW、IPS 等），还需要专门针对数据库部署独立安全审计产品，对关键的数据库操作行为进行审计，做到违规行为发生时及时告警，事故发生后精确溯源。 不过，审计关键应用程序和数据库不是一项简单工作。特别是数据库系统，服务于各有不同权限的大量用户，支持高并发的事务处理，还必须满足苛刻的服务水平要求。商业数据库软件内置的审计功能无法满足审计独立性的基本要求，还会降低数据库性能并增加管理费用。 2.需求分析 随着信息技术的发展，XXX已经建立了比较完善的信息系统，数据库中承载的信息越来越受到公司相关部门、领导的重视。同时数据库中储存着诸如XXX等极其重要和敏感的信息。这些信息一旦被篡改或者泄露，轻则造成企业或者社会的经济损失，重则影响企业形象甚至社会安全。 通过对XXX的深入调研，XXX面临的安全隐患归纳如下：
1.重点、难点的分析 1.对本工程项目实施的重点、难点分析 重点、难点一：本工程建设规模大，涉及专业多，确保工期目标的实现，是本工程的重点； 重点、难点二：隐蔽工程和特殊部位的正确处理，确保工程质量和效果，是本工程的难点； 重点、难点三：绿色环保材料的选用，以及材料的管理，是本工程的重点； 重点、难点四：安全、文明、环保施工，降低噪音，是本工程的重点。 针对本工程项目实施重点、难点的解决方案 人员保证措施 1）项目部人员组成：因为考虑到本项目的质量要求、工期及总体工程量较大，公司特安排人员具有多项大型会场高档装饰工程的施工管理经验，以保证项目部整体管理力量。 2）项目经理及施工管理人员均常驻现场，每周不少于6天，每天不少于1小时，并接受业主及监理进行考勤，共同抓好安全文明施工，确保工程质量、材料即时到位，确保本工程按质按期完成施工任务。 3）为保证工期的按时完成，公司将组织精兵强将，迅速熟悉图纸，领会设计意图，即时进场开场施工工作，工期紧张时分二班，24小时施工，同时承诺重大节日，施工现场不间隙、不停工，充分利用
时间，保证施工任务的完成。 4）劳动力的管理 施工队伍组成及进场计划：本项目确保施工质量，后备约20～30人的队伍随时参与工程建设，确保工期。 充分挖掘劳动资源，合理安排和节约使用劳动力。 正确处理国家、集体和劳动者个人的利益关系，充分调动广大职工的积极性。 编制劳动力使用计划，合理、节约、控制使用劳动力，改善劳动组织，完善劳动的分工和协作关系，制订劳动力调配管理办法，挖掘劳动潜力。 建立健全劳动定额管理制度，确定合理定额水平，监督劳动定额的使用。 合理执行工资制度，控制工资限额，搞好工资分配，正确掌握奖惩制度。 编制劳动计划，确定计划期内劳动力的需要量，随着施工过程的进展合理调整劳动力，保证劳动力的协调和合理使用。 提高劳动生产率的措施 开展科学研究，促进技术进步。全面开展科学研究工作，促进建筑技术的进步。 提高管理水平，科学的组织生产。 改善劳动组织，建立相应的劳动组织，形成有利于个人技术的发挥，以及工种之间的分配和协作的机制，建立岗位责任制，以促进劳
1、load 方法装入数据： export to tempfile of del select * from tablename where not 清理条件； load from tempfile of del modified by delprioritychar replace into tablename nonrecoverable； 说明： 在不相关的数据表export数据时，可以采取并发的形式，以提高效率； tablename指待清理table的名称； modified by delprioritychar防止数据库记录中存在换行符,导致数据无法装入的情况; replace into对现数据库中的内容进行替换，即将现行的数据记录清理，替换为数据文件内容； nonrecoverable无日志方式装入； 2、查找当前的应用： db2 list application grep btpdbs; 3、删除当前正在使用的application: db2 "force application (id1,id2,id3)" id1,id2,id3 是list显示的应用号； 4、查看当前应用号的执行状态： db2 get snapshot for application agentid 299 grep row 5、查看数据库参数： db2 get db cfg for //当前数据库可以省略 6、修改数据库的log数据： db2 update db cfg using <参数名> <参数值> 7、db2stop force的用法： 在进行bind的时候出现如下错误： sql0082can error has occurred which has terminated processing. sql0092nno package was created because of previous errors. sql0091nbinding was ended with "3" errors and "0" warnings. 主要是表文件被加锁，不能继续使用； 在进行stop的时候报错：db2stop 8/03/2005 21:46:530 0 sql1025nthe database manager was not stopped because databases are still active.
MSSQL2000 中没有日志文件的数据库恢复方法 由于种种原因， 我们如果当时仅仅备份了 mdf 文件，那么恢复起来就是一件 很麻烦的事情了。 如果您的 mdf 文件是当前数据库产生的，那么很侥幸，也许你使用 sp_attach_db 或者 sp_attach_single_file_db 可以恢复数据库，但是会出现类 似下面的提示信息 ########################################################## 设备激活错误。 物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。 已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。 ########################################################## 但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也 许上述办法就行不通了。你也许会得到类似下面的错误信息 ########################################################## 服务器: 消息 1813，级别 16，状态 2，行 1 未能打开新数据库 'test'。CREATE DATABASE 将终止。 设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。 ########################################################## 当出现以上问题时，恢复的办法如下: A.我们使用默认方式建立一个供恢复使用的数据库(数据库名应该与要恢复 的数据库相同，如 test)。可以在 SQL Server Enterprise Manager 里面建立。 B.停掉数据库服务器。 C.将刚才生成的数据库的日志文件 test_log.ldf 删除，用要恢复的数据库 mdf 文件覆盖刚才生成的数据库数据文件 test_data.mdf。 D.启动数据库服务器。此时会看到数据库 test 的状态为“置疑”。这时候 不能对此数据库进行任何操作。 E.设置数据库允许直接操作系统表。此操 作可以在 SQL Server Enterprise Manager 里面选择数据库服务器，按右键，选 择“属性”， 在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。 也可以使用如下语句来实现。
XX集团XX有限公司XX防控管理系统 实施方案 XX科技有限公司
一、软件项目实施方案概述 软件产品用户购买软件产品之后，不能立即进行使用，需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作，我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。 项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容。下面将分别介绍每个项目实施阶段。 二、软件项目实施方案 （一）项目启动阶段 此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。 阶段主任务 1、成立项目组：
部门经理接到实施申请后，任命项目经理，指定项目目标，由部门经理及项目经理一起指定项目组成员及成员任务，并报总经理签署《项目任务书》。 2、前期调研： 项目经理及项目组成员，在商务人员配合下，建立与用户的联系，对合同、用户进行调研。填写《用户及合同信息表》。在项目商务谈判中，商务经理积累了大量的信息，项目组首先应收集商务和合同信息，并与商务经理一起识别哪些个体和组织是项目的干系人，确定他们的需求和期望，以确保项目开发顺利。 3、编制《项目总体计划》： 《项目总体计划》主要包括以下几方面内容：项目描述，项目目标、主要项目阶段、里程碑、可交付成果等。 4、启动会： 项目组与用户共同召开的宣布项目实施正式开始的会议。会程安排如下： 共同组建项目实施组织，实施组织的权利和职责；双方签署《项目实施协议》； 项目组介绍《项目总体计划》和《项目实施协议》，包括以下内容：项目目标、主要项目阶段、里程碑、可交付成果及计划的职责分配（包括用户的）； 项目实施中项目管理的必要性和如何进行项目管理，项目的质量如何控制； 项目实施中用户的参与和领导的支持的重要作用； 阶段验收、技术交接和项目结束后如何对用户提供后续服务。 （二）需求调研确认阶段 此阶段的主要工作是软件公司的项目实施人员向用户调查用户对系统的需求，包括管理流程调研、功能需求调研、报表要求调研、查询需求调研等，实施人员调研完成后，会编写《需求调研分析手册》，并交付用户进行确认，待用户对《需求调研分析手册》上所提到的需求确认完毕后，项目实施人员将以此为依据进行软件功能的实现。如果用户又提出新的需求，实施人员将分析需求的难度及对整个系统的影响程度来确定是否给予实现。 需求调研阶段具体包括如下内容： 1、进行需求调研准备 2、编制《需求调研计划》
方法一、 1 / 4
2 / 4 方法二、
MS SQL清除日志的命令 如何清除sql server 日志? 设置数据库为简单模式,自动收缩 1．打开查询分析器，输入命令 backup log databasename with no_log 2.再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M 数,直接输入这个数,确定就可以了。 dbcc shrinkfile (databasename_log,truncateonly) 方法三、 1: 删除LOG 第1步：分离数据库企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库 第2步：删除LOG文件 第3布：附加数据库企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库 此法生成新的LOG，大小只有500多K 再将此数据库设置自动收缩 方法四、 EXEC sp_detach_db @dbname = 'pubs' EXEC sp_attach_single_file_db @dbname = 'pubs', @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf' 方法五、 Use Database_Name Backup Log Database_Name With No_log dbcc shrinkfile (Database_Name_Log,truncateonly) Go 方法六、 直接在查询分析那里执行backup log databasename with no_log 然后回到企业管理器把数据库收缩一下（可能需另外设置属性） 3 / 4
黑马程序员：高并发解决方案 一、什么是高并发 高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。 响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。 吞吐量：单位时间内处理的请求数量。 QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。 二、什么是秒杀 秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于电商网站中一些稀缺或者特价商品，电商网站一般会在约定时间点对其进行限量销售，因为这些商品的特殊性，会吸引大量用户前来抢购，并且会在约定的时间点同时在秒杀页面进行抢购。
此种场景就是非常有特点的高并发场景，如果不对流量进行合理管控，肆意放任大流量冲击系统，那么将导致一系列的问题出现，比如一些可用的连接资源被耗尽、分布式缓存的容量被撑爆、数据库吞吐量降低，最终必然会导致系统产生雪崩效应。 一般来说，大型互联网站通常采用的做法是通过扩容、动静分离、缓存、服务降级及限流五种常规手段来保护系统的稳定运行。 三、扩容 由于单台服务器的处理能力有限，因此当一台服务器的处理能力接近或已超出其容量上限时，采用集群技术对服务器进行扩容，可以很好地提升系统整体的并行处理能力，在集群环境中，节点的数量越多，系统的并行能力和容错性就越强。在无状态服务下，扩容可能是迄今为止效果最明显的增加并发量的技巧之一。从扩容方式角度讲，分为垂直扩容（scale up）和水平扩容（scale out）。垂直扩容就是增加单机处理能力，怼硬件，但硬件能力毕竟还是有限；水平扩容说白了就是增加机器数量，怼机器，但随着机器数量的增加，单应用并发能力并不一定与其呈现线性关系，此时就可能需要进行应用服务化拆分了。 从数据角度讲，扩容可以分为无状态扩容和有状态扩容。无状态扩容一般就是指我们的应用服务器扩容；有状态扩容一般是指数据存储扩容，要么将一份数据拆分成不同的多份，即sharding，要么就整体复制n份，即副本。sharding遇
技术方案、项目实施方案 若我单位中标，将按如下计划完成此项工程： 一、技术方案 1、紧密与招标方及各使用部门联系，根据中标产品及使用现场测量的实际情况，为采购方提供完美的布置方案。 2、在公司内专门成立负责该工程事项的小组，由总经理牵头，并由供应、质检、销售等各部门指定专人负责，整个过程完全按照招标方要求的材质标准及所中标的产品进行联审，随时将产品质量执行及生产进度情况汇报于协助小组组长。 3、在生产进行到白坯（半成品）阶段，邀请招标方领导前往公司就产品生产质量进度情况进行检查，全过程由总经理亲自陪同。 4、全部产品生产完毕并办理手续后，根据招标方工程进度情况，等候送货通知。 5、挑选精炼的安装队伍，指定专人负责，按质按期完成安装工作。 6、本公司随时提供跟踪服务，按招标中收获服务计划及承诺做好售后服务工作。 7、义务配合贵单位各部门做好办公室环境的布局及调整工作。 8、招标货物的成套供应、运输保障： ***********久经考验的物流配送体系将再次承担此次产品的运输任务，为了确保产品能准时、安全的送到指定地点，在运输部门的鼎力支持下，我们特制定如下运输计划：（1）运输方式首选公路运输，预备多种方案，以确保安装工作顺利进行，按时向客户交货。 （2）产品在生产基地发货时，全部按安装地点分类包装，考虑到实际情况，因此将加厚包装，避免运输途中损坏。 （3）由于此次产品数量众多，因此在正式交货时应先运输一部分产品到广元的库房，以保证交货时有足够的产品以备安装。 （4）公路运输由***********的专业运输队负责运达，装卸产品由***********专业安装人员负责，以避免装卸产品时发生损坏情况，每次运输都配有专人跟车押送。 （5）工程管理小组配有专业调度人员负责产品的运输调度，使整个运输过程动态有序的
1.大型分布式数据库解决方案 企业数据库的数据量很大时候，即使服务器在没有任何压力的情况下，某些复杂的查询操作都会非常缓慢，影响最终用户的体验；当数据量很大的时候，对数据库的装载与导出，备份与恢复，结构的调整，索引的调整等都会让数据库停止服务或者高负荷运转很长时间，影响数据库的可用性和易管理性。 分区表技术 让用户能够把数据分散存放到不同的物理磁盘中，提高这些磁盘的并行处理能力，达到优化查询性能的目的。但是分区表只能把数据分散到同一机器的不同磁盘中，也就是还是依赖于一个机器的硬件资源，不能从根本上解决问题。 分布式分区视图 分布式分区视图允许用户将大型表中的数据分散到不同机器的数据库上，用户不需要知道直接访问哪个基础表而是通过视图访问数据，在开发上有一定的透明性。但是并没有简化分区数据集的管理、设计。用户使用分区视图时，必须单独创建、管理每个基础表（在其中定义视图的表）,而且必须单独为每个表管理数
据完整性约束，管理工作变得非常复杂。而且还有一些限制，比如不能使用自增列，不能有大数据对象。对于全局查询并不是并行计算，有时还不如不分区的响应快。 库表散列 在开发基于库表散列的数据库架构，经过数次数据库升级，最终采用按照用户进行的库表散列，但是这些都是基于自己业务逻辑进行的，没有一个通用的实现。客户在实际应用中要投入很大的研发成本，面临很大的风险。 面对海量数据库在高并发的应用环境下，仅仅靠提升服务器的硬件配置是不能从根本上解决问题的，分布式网格集群通过数据分区把数据拆分成更小的部分，分配到不同的服务器中。查询可以由多个服务器上的CPU、I/O来共同负载，通过各节点并行处理数据来提高性能；写入时，可以在多个分区数据库中并行写入，显著提升数据库的写入速度。
一数据库日志文件管理 SQL SERVER日志清除的两种方法 在使用过程中大家经常碰到数据库日志非常大的情况，在这里介绍了两种处理方法...... 方法一： 一般情况下，SQL数据库的收缩并不能很大程度上减小数据库大小，其主要作用是收缩日志大小，应当定期进行此操作以免数据库日志过大。 1、设置数据库模式为简单模式：打开SQL企业管理器，在控制台根目录中依次点开Microsoft SQL Server-->SQL Server组-->双击打开你的服务器-->双击打开数据库目录-->选 择你的数据库名称-->然后点击右键选择属性-->选择选项-->在故障还原的模式中选择"简单"，然后按确定保存。 2、在当前数据库上点右键，看所有任务中的收缩数据库，一般里面的默认设置不用调整，直接点确定。 3、收缩数据库完成后，建议将您的数据库属性重新设置为标准模式，操作方法同第一点，因为日志在一些异常情况下往往是恢复数据库的重要依据 方法二： 如果日志文件过于庞大，使用数据库收缩已经不能解决问题，可以考虑使用以下的方法。 对数据库进行分离，分离后将日志文件改名，然后重新附加数据库，此时会提示没有正确的日志文件，不要管，在附加过程中会重新生成日志文件。 完成后，在数据库属性中重新设置日志文件的大小，可设置为5G，这样就把原来的日志清除掉了。 注意：该方法在使用过程中，可能对数据库分离时间点上的数据有影响，因此，如果出现问题，请重新恢复该部分数据。或者在停止业务一段时间后再进行操作。 在SQL Server 2000企业管理器里面收缩数据库日志 操作环境：Windows 2000 Server 简体中文版+ sp4、SQL Server 2000标准版+sp4 任务描述： 在企业管理器里面收缩数据库日志 以下为操作截屏：