Ⅰ Web应用常见的安全漏洞有哪些
OWASP总结了现有Web应用程序在安全方面常见的十大漏洞分别是：非法输入、失效的访问控制、失效的账户和线程管理、跨站脚本攻击、缓存溢出问题、注入式攻击、异常错误处理、不安全的存储、程序拒绝服务攻击、不安全的配置管理等。
非法输入
Unvalidated Input
在数据被输入程序前忽略对数据合法性的检验是一个常见的编程漏洞。随着OWASP对Web应用程序脆弱性的调查，非法输入的问题已成为大多数Web应用程序安全漏洞方面的一个普遍现象。
失效的访问控制
Broken Access Control
大部分企业都非常关注对已经建立的连接进行控制，但是，允许一个特定的字符串输入可以让攻击行为绕过企业的控制。
失效的账户和线程管理
Broken Authentication and Session Management
有良好的访问控制并不意味着万事大吉，企业还应该保护用户的密码、会话令牌、账户列表及其它任何可为攻击者提供有利信息、能帮助他们攻击企业网络的内容。
跨站点脚本攻击
Cross Site Scripting Flaws
这是一种常见的攻击，当攻击脚本被嵌入企业的Web页面或其它可以访问的Web资源中，没有保护能力的台式机访问这个页面或资源时，脚本就会被启动，这种攻击可以影响企业内成百上千员工的终端电脑。
缓存溢出问题
Buffer Overflows
这个问题一般出现在用较早的编程语言、如C语言编写的程序中，这种编程错误其实也是由于没有很好地确定输入内容在内存中的位置所致。
注入式攻击
Injection Flaws
如果没有成功地阻止带有语法含义的输入内容，有可能导致对数据库信息的非法访问，在Web表单中输入的内容应该保持简单，并且不应包含可被执行的代码。
异常错误处理
Improper Error Handling
当错误发生时，向用户提交错误提示是很正常的事情，但是如果提交的错误提示中包含了太多的内容，就有可能会被攻击者分析出网络环境的结构或配置。
不安全的存储
Insecure Storage
对于Web应用程序来说，妥善保存密码、用户名及其他与身份验证有关的信息是非常重要的工作，对这些信息进行加密则是非常有效的方式，但是一些企业会采用那些未经实践验证的加密解决方案，其中就可能存在安全漏洞。
程序拒绝服务攻击
Application Denial of Service
与拒绝服务攻击 (DoS)类似，应用程序的DoS攻击会利用大量非法用户抢占应用程序资源，导致合法用户无法使用该Web应用程序。
不安全的配置管理
Insecure Configuration Management
有效的配置管理过程可以为Web应用程序和企业的网络架构提供良好的保护。
以上十个漏洞并不能涵盖如今企业Web应用程序中的全部脆弱点，它只是OWASP成员最常遇到的问题，也是所有企业在开发和改进Web应用程序时应着重检查的内容。
Ⅱ 墨菲定律视角下的数据库入侵防御
作者：汉领信息 两块
企业对数据资产的安全防护存在多项工作，数据备份安全、数据存储安全、数据脱敏及加密……以可用性为主的业务安全观点人群中，大多还没有完全理解数据库安全的重要性，而据前瞻性统计发现，越来越多的企业信息安全负责人开始将数据库安全细分领域列入自己的备忘清单。业务连续性为企业组织的根本核心，而业务安全和数据安全是企业长久发展的安全保障，在以企业数据资产为核心竞争力的现下，数据库作为企业组织“核心竞争力”–数据资产–的容器，承载了企业核心数据，成为业务运行和数据保护的基础设施，数据库的安全防御问题已跃至CTO/CIO的工作内容象限的榜首。
企业组织的数据库体系，不仅仅是数据库软件平台本身，不会流动的数据没有意义，当我们考虑数据库安全的时候，显然我们需要合理评估数据库的受攻击面大小，数据库访问涉及的认证、授权和审计问题，由于开发人员疏忽带来的软件漏洞和运维人员的管理不善等。各种各样的风险都可能产生并带来可怕的后果，笔者实验室通过收集各漏洞平台及企业安全运营者的反馈数据库安全信息，参考OWASP TOP 10制定了数据库应用防御的十大数据库风险威胁列表。
十大数据库安全威胁（DB Vuln Top 10）
1. 权限滥用
2. 特权提升
3. 数据库软件漏洞
4. sql注入
5. 审计记录缺失
6. 拒绝服务
7. 通信协议漏洞
8. 身份验证不足
9. 敏感数据泄露
10. 安全配置不规范
答案就是墨菲定律，它阐述了一个事实：如果事情有变糟糕（发生）的可能，不管这种可能性有多小，它总会发生。
此后在技术界也不胫而走，并不是我要将其强加在数据库安全领域，因为它道出了一个法则，即安全风险必将由可能性变为突发性的事实。
从墨菲定律来观察数据库入侵防御，我们要持以积极的态度，既然数据库安全风险一定会发生，那我们一定要顺应必然性，积极应对，做好事件应急和处置。在数据库安全防御方面来说，要科学合理规划全面积极的应对方案，必须做到事前主动防御、事中及时阻断、事后完整审计。
根据墨菲定律可总结对数据库入侵防御的启示：
1. 不能忽视数据库风险小概率事件
虽然数据库安全事件不断发生，但仍有一定数量的安全负责人认为，企业安全防护已经从物理层、网络层、计算主机层、应用层等进行了多重防御，网络边界严格准入控制，外部威胁情报和内部态势感知系统能完美配合，业务数据早已经过层层保护，安全威胁不可能被利用发生数据库安全事件。
由于小概率事件在一次实验或活动中发生的可能性很小，因此，就给人一种错误的理解，即在一次活动中不会发生。与事实相反，正是由于这种错觉，加大了事件发生的可能性，其结果是事故可能频繁发生。虽然事件原因是复杂的，但这却说明小概率事件也会常发生的客观事实。
墨菲定律正是从强调小概率事件的重要性的角度启示我们，虽然数据库安全风险事件发生的概率很小，但在入侵防御体系活动中，仍可能发生且必将发生，因此不能忽视。
2. 在数据库安全中积极应用墨菲定律
1）强化数据库入侵防御的安全认知
数据库已经成为企业安全防护的核心，预防数据库不安全状态的意外性事件发生，认识数据库安全威胁事件可能发生的必然性，必须要采取事前预防措施，从网络层、应用层和数据库层，涵盖业务系统（中间件）和运维DBA，全面管控，提前谋划。既然数据库入侵事件无可避免，那一定要保证完整原始的数据库访问记录，以供审计取证留存证据，做到有据可查。
2）规范安全管理，正确认识数据库安全控制
安全管理的目标是杜绝事故的发生，而事故是一种不经常发生的意外事件，这些意外事件发生的概率一般比较小，由于这些小概率事件在大多数情况下不发生，所以，往往管理疏忽恰恰是事故发生的主观原因。墨菲定律告诫我们，数据库及业务数据的安全控制不能疏忽。要想保证数据库安全，必须从基础做起，对数据库的基本安全配置，要形成统一的安全基线，对数据库的访问行为要做到 “白名单化”，采取积极的预防方法和措施，消除意外的事件发生。
3）转变观念，数据库入侵防御变被动为主动
传统安全管理是被动的安全管理，是在安全管理活动中采取安全措施或事故发生后，通过总结教训，进行“亡羊补牢”式的管理。随着IT网络技术迅速发展，安全攻击方式不断变化，新的安全威胁不断涌现，发生数据库安全事件的诱因增多，而传统的网络型入侵防御系统模式已难于应付当前对数据库安全防御的需求。为此，不仅要重视已有的安全威胁，还要主动地去识别新的风险，主动学习，模态分析，及时而准确的阻断风险活动，变被动为主动，牢牢掌握数据库入侵防御的主动权。
1. 数据库入侵防御系统串联与并联之争
数据库入侵防御系统，可以通过串联或旁路部署的方式，对业务系统与数据库之间的访问行为进行精确识别、精准阻断。不仅如此，合理使用还能具有事前主动防御和事后审计追溯的能力。
不过，部分用户认为旁路的阻断行为效果不佳，而串联进网络实现实时阻断，又担心影响业务访问时。
串联模式部署在业务系统与数据库中间，通过流量协议解码对所有SQL语句进行语法解析，审核基于TCP/IP五元组（来往地址、端口与协议）、准入控制因素和数据库操作行为的安全策略，结合自主动态建模学习的白名单规则，能够准确识别恶意数据库指令，及时阻断会话或准确拦截恶意操作语句。串联模式部署最大风险在于不能出现误判，否则影响正常语句通过，此必需要系统的SQL语句解析能力足够精确，并且能够建立非常完善的行为模型，在发现危险语句时，能够在不中断会话的情况下，精准拦截风险语句，且不影响正常访问请求。因此，若想数据库入侵防御系统发挥最佳效果，必须串联在数据库的前端，可以物理串联（透明桥接）或逻辑串联（反向代理）。
旁路部署模式，目前常用方式是通过发送RESET指令进行强行会话重置，此部署方式在较低流量情况下效果最佳。如在业务系统大并发情况下，每秒钟SQL交易量万条以上，这种旁路识别阻断有可能出现无法阻断情况，且会出现延迟。有可能因为延迟，阻断请求发送在SQL语句执行之后，那么反倒影响了正常业务请求。所以在高并发大流量场景下，如果要实现实时精准阻断拦截效果，就要求数据库入侵防御系统具有超高端的处理性能。
至于串联部署还是旁路部署更为合适，需要匹配相应的业务系统场景。数据库入侵防御系统最终奥义是它的防御效果，即对风险语句的精准阻断能力，从墨菲定律对比分析，旁路部署有阻断请求的可能性则必然会发生。而串联存在影响业务访问的担忧，那它始终都会发生，而正视这种风险，让我们对数据库入侵防御系统的精准阻断能力有更高要求，尽可能将这种风险降到最低。
2. 数据库入侵防御系统串联实时同步阻断与异步阻断之争
相对数据库入侵防御系统的串并联之争来讲，串联实现同步阻断与异步阻断更为细分了，市面上存在两类串联的数据库入侵防御系统；
一类就是以IBM Guardium为代表的本地代理引擎在线监听异步阻断，当有危险语句通过代理到DBMS时，代理会将内容信息副本发至分析中心，由中心判断是否违法或触犯入侵防御规则，进而给代理程序发出阻断指令，很显然这种部署的好处是不局限与数据库的网络环境，ip可达即可，而坏处就更明显了，那就是agent与Center通信期间，sql访问是放行的，也就是如果在前面几个包就出现了致命攻击语句，那么这次攻击就会被有效执行，即防御体系被有效绕过。
另一类就是以国内厂商汉领信息为代表的串联实时同步阻断，当有危险语句通过串联数据库入侵防御系统时，入侵防御系统若监测到风险语句，立马阻断；无风险的语句放行，这种模式及立马分析立马判断。也很显然，这种部署模式的好处是小概率事件或预谋已久的直接攻击语句也会被实时阻断；而坏处也非常明显，那就是处理效率，如果数据库入侵防御系统处理效率不行，那就会出现排队等待的状态，业务的连续性就造成了影响。关键就是要把握这个平衡点，至少要达到无感知，这个点的取舍就取决于各个数据库安全厂商处理sql语句的算法能力了。
墨菲定律并不复杂，将它应用到数据库入侵防御领域，揭示了在数据库安全中不能忽视的小概率风险事件，要正视墨菲定律转为积极响应，应充分理解墨菲定律，抵制 “数据库层层保护不存在风险”、“别人都是这样做”、“数据库入侵防御系统并联不会误阻断” 等错误认识，牢记只要存在风险隐患，就有事件可能，事件迟早会发生，我们应当杜绝习惯性认知，积极主动应对数据库安全风险。
Ⅲ 数据库mysql创建表格老是出错，看不懂英文提示
来自：51CTO（作者：superZS）
我在刚开始学习数据库的时候，没少走弯路。经常会遇到各种稀奇古怪的 error 信息，遇到报错会很慌张，急需一个解决问题的办法。跟无头苍蝇一样，会不加思索地把错误粘到网络上，希望赶紧查找一下有没有好的处理问题的方法。我想这个应该是刚从事数据库的小白，都会遇到窘境。
今天就给大家列举 MySQL 数据库中，最经典的十大错误案例，并附有处理问题的解决思路和方法，希望能给刚入行，或数据库爱好者一些帮助，今后再遇到任何报错，我们都可以很淡定地去处理。
学习任何一门技术的同时，其实就是自我修炼的过程。沉下心，尝试去拥抱数据的世界！
Top 1：
Too many connections（连接数过多，导致连接不上数据库，业务无法正常进行）
问题还原
解决问题的思路：
1、首先先要考虑在我们 MySQL 数据库参数文件里面，对应的 max_connections 这个参数值是不是设置的太小了，导致客户端连接数超过了数据库所承受的最大值。
● 该值默认大小是151，我们可以根据实际情况进行调整。
● 对应解决办法：set global max_connections=500
但这样调整会有隐患，因为我们无法确认数据库是否可以承担这么大的连接压力，就好比原来一个人只能吃一个馒头，但现在却非要让他吃 10 个，他肯定接受不了。反应到服务器上面，就有可能会出现宕机的可能。
所以这又反应出了，我们在新上线一个业务系统的时候，要做好压力测试。保证后期对数据库进行优化调整。
2、其次可以限制 Innodb 的并发处理数量，如果 innodb_thread_concurrency = 0（这种代表不受限制） 可以先改成 16或是64 看服务器压力。如果非常大，可以先改的小一点让服务器的压力下来之后,然后再慢慢增大,根据自己的业务而定。个人建议可以先调整为 16 即可。
MySQL 随着连接数的增加性能是会下降的，可以让开发配合设置 thread pool，连接复用。在MySQL商业版中加入了thread pool这项功能
另外对于有的监控程序会读取 information_schema 下面的表，可以考虑关闭下面的参数
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0
Top 2：（主从复制报错类型）
Last_SQL_Errno: 1062 （从库与主库数据冲突）
Last_Errno: 1062
Last_Error: Could not execute Write_rows event on table test.t;
Duplicate entry '4' for key 'PRIMARY',
Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY;
the event's master log mysql-bin.000014, end_log_pos 1505
针对这个报错，我们首先要考虑是不是在从库中误操作导致的。结果发现，我们在从库中进行了一条针对有主键表的 sql 语句的插入，导致主库再插入相同 sql 的时候，主从状态出现异常。发生主键冲突的报错。
解决方法：
在确保主从数据一致性的前提下，可以在从库进行错误跳过。一般使用 percona-toolkit 中的 pt-slave-restart 进行。
在从库完成如下操作
[root@zs bin]# ./pt-slave-restart -uroot -proot123
2017-07-20T14:05:30 p=...,u=root node4-relay-bin.000002 1506 1062
之后最好在从库中开启 read_only 参数，禁止在从库进行写入操作
Last_IO_Errno: 1593（server-id冲突）
Last_IO_Error:
Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids;
these ids must be different for replication to work
(or the --replicate-same-server-id option must be used on slave but this
does not always make sense; please check the manual before using it)
这个报错出现之后，就看一目了然看到两台机器的 server-id 是一样的。
在搭建主从复制的过程中，我们要确保两台机器的 server-id 是唯一的。这里再强调一下 server-id 的命名规则（服务器 ip 地址的最后一位+本 MySQL 服务的端口号）
解决方法：
在主从两台机器上设置不同的 server-id。
Last_SQL_Errno: 1032（从库少数据，主库更新的时候，从库报错）
Last_SQL_Error:
Could not execute Update_rows event on table test.t; Can't find record
in 't', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the
event's master log mysql-bin.000014, end_log_pos 1708
解决问题的办法：
根据报错信息，我们可以获取到报错日志和position号，然后就能找到主库执行的哪条sql，导致的主从报错。
在主库执行：
/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=decode-rows /data/mysql/mysql-bin.000014 |grep -A 10 1708 > 1.log
cat 1.log
#170720 14:20:15 server id 3 end_log_pos 1708 CRC32 0x97b6bdec Update_rows: table id 113 flags: STMT_END_F
### UPDATE `test`.`t`
### WHERE
### @1=4 /* INT meta=0 nullable=0 is_null=0 */
### @2='dd' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
### SET
### @1=4 /* INT meta=0 nullable=0 is_null=0 */
### @2='ddd' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
# at 1708
#170720 14:20:15 server id 3 end_log_pos 1739 CRC32 0xecaf1922 Xid = 654
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
获取到 sql 语句之后，就可以在从库反向执行 sql 语句。把从库缺少的 sql 语句补全，解决报错信息。
在从库依次执行：
mysql> insert into t (b) values ('ddd');
Query OK, 1 row affected (0.01 sec)
mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)
mysql> exit
Bye
[root@node4 bin]# ./pt-slave-restart -uroot -proot123
2017-07-20T14:31:37 p=...,u=root node4-relay-bin.000005 283 1032
Top 3：MySQL安装过程中的报错
[root@zs data]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &[1] 3758
[root@zs data]# 170720 14:41:24 mysqld_safe Logging to '/data/mysql/error.log'.
170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql170720
14:41:25 mysqld_safe mysqld from pid file /data/mysql/node4.pid ended
170720 14:41:24 mysqld_safe Starting mysqld daemon with databases from /data/mysql2017-07-20
14:41:25 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated.
Please use --explicit_defaults_for_timestamp server option
(see documentation for more details)./usr/local/mysql/bin/mysqld:
File '/data/mysql/mysql-bin.index' not found (Errcode: 13 - Permission denied)
2017-07-20 14:41:25 4388 [ERROR] Aborting
解决思路：
遇到这样的报错信息，我们要学会时时去关注错误日志 error log 里面的内容。看见了关键的报错点 Permission denied。证明当前 MySQL 数据库的数据目录没有权限。
解决方法：
[root@zs data]# chown mysql:mysql -R mysql
[root@zs data]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &
[1] 4402
[root@zs data]# 170720 14:45:56 mysqld_safe Logging to '/data/mysql/error.log'.
170720 14:45:56 mysqld_safe Starting mysqld daemon with databases from /data/mysql
启动成功。
如何避免这类问题，个人建议在安装 MySQL 初始化的时候，一定加上--user=mysql，这样就可以避免权限问题。
./mysql_install_db --basedir=/usr/local/mysql/ --datadir=/data/mysql/ --defaults-file=/etc/my.cnf --user=mysql
Top 4：数据库密码忘记的问题
[root@zs ~]# mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
[root@zs ~]# mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
我们有可能刚刚接手别人的 MySQL 数据库，而且没有完善的交接文档。root 密码可以丢失或者忘记了。
解决思路：
目前是进入不了数据库的情况，所以我们要考虑是不是可以跳过权限。因为在数据库中，mysql数据库中user表记录着我们用户的信息。
解决方法：
启动 MySQL 数据库的过程中，可以这样执行：
/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf --skip-grant-tables &
这样启动，就可以不用输入密码，直接进入 mysql 数据库了。然后在修改你自己想要改的root密码即可。
update mysql.user set password=password('root123') where user='root';
Top 5：truncate 删除数据，导致自动清空自增ID，前端返回报错 not found。
这个问题的出现，就要考虑下 truncate 和 delete 的区别了。
看下实验演练：
首先先创建一张表；
CREATE TABLE `t` (
`a` int(11) NOT NULL AUTO_INCREMENT,
`b` varchar(20) DEFAULT NULL,
PRIMARY KEY (`a`),
KEY `b` (`b`)
) ENGINE=InnoDB AUTO_INCREMENT=300 DEFAULT CHARSET=utf8
插入三条数据：
mysql> insert into t (b) values ('aa');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t (b) values ('bb');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t (b) values ('cc');
Query OK, 1 row affected (0.00 sec)
mysql> select * from t;
+-----+------+
| a | b |
+-----+------+
| 300 | aa |
| 301 | bb |
| 302 | cc |
+-----+------+
3 rows in set (0.00 sec)
先用 delete 进行删除全表信息，再插入新值。
结果发现 truncate 把自增初始值重置了，自增属性从1开始记录了。当前端用主键id进行查询时，就会报没有这条数据的错误。
个人建议不要使用 truncate 对表进行删除操作，虽然可以回收表空间，但是会涉及自增属性问题。这些坑，我们不要轻易钻进去。
Top 6：
阿里云 MySQL 的配置文件中，需要注意一个参数设置就是：
lower_case_table_names = 0;默认情况
lower_case_table_names = 1;是不区分大小写 . 如果报你小写的表名找不到, 那你就把远端数据库的表名改成小写 , 反之亦然 . 注意 Mybatis 的 Mapper 文件的所有表名也要相应修改
Top 7：
有同学经常会问张老师，为什么我的数据库总会出现中文乱码的情况。一堆？？？？不知道怎么回事。当向数据库中写入创建表，并插入中文时，会出现这种问题。此报错会涉及数据库字符集的问题。
解决思路：
对于中文乱码的情况，记住老师告诉你的三个统一就可以。还要知道在目前的mysql数据库中字符集编码都是默认的UTF8
处理办法：
1、数据终端，也就是我们连接数据库的工具设置为 utf8
2、操作系统层面；可以通过 cat /etc/sysconfig/i18n 查看；也要设置为 utf8
3、数据库层面；在参数文件中的 mysqld 下，加入 character-set-server=utf8。
Emoji 表情符号录入 mysql 数据库中报错。
Caused by: java.sql.SQLException: Incorrect string value: '\xF0\x9F\x98\x97\xF0\x9F...' for column 'CONTENT' at row 1
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1074)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4096)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4028)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2734)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155)
at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1379)
解决思路：针对表情插入的问题，一定还是字符集的问题。
处理方法：我们可以直接在参数文件中，加入
vim /etc/my.cnf
[mysqld]
init-connect='SET NAMES utf8mb4'
character-set-server=utf8mb4
注：utf8mb4 是 utf8 的超集。
Top 8：使用 binlog_format=statement 这种格式，跨库操作，导致从库丢失数据，用户访问导致出现错误数据信息。
当前数据库二进制日志的格式为：binlog_format=statement
在主库设置binlog-do-db=mydb1（只同步mydb1这一个库）
在主库执行use mydb2；
insert into mydb1.t1 values ('bb');这条语句不会同步到从库。
但是这样操作就可以；
use mydb1;
insert into mydb1.t1 values ('bb');因为这是在同一个库中完成的操作。
在生产环境中建议使用binlog的格式为row，而且慎用binlog-do-db参数。
Top 9：MySQL 数据库连接超时的报错 ；
org.hibernate.util.JDBCExceptionReporter - SQL Error:0, SQLState: 08S01
org.hibernate.util.JDBCExceptionReporter - The last packet successfully received from the server was43200 milliseconds ago.The last packet sent successfully to the server was 43200 milliseconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection 'autoReconnect=true' to avoid this problem.
org.hibernate.event.def.AbstractFlushingEventListener - Could not synchronize database state with session
org.hibernate.exception.JDBCConnectionException: Could not execute JDBC batch update
com.mysql.jdbc.exceptions.jdbc4.: Connection.close() has already been called. Invalid operation in this state.
org.hibernate.util.JDBCExceptionReporter - SQL Error:0, SQLState: 08003
org.hibernate.util.JDBCExceptionReporter - No operations allowed after connection closed. Connection was implicitly closed e to underlying exception/error:
** BEGIN NESTED EXCEPTION **
大多数做 DBA 的同学，可能都会被开发人员告知，你们的数据库报了这个错误了。赶紧看看是哪里的问题。
这个问题是由两个参数影响的，wait_timeout 和 interactive_timeout。数据默认的配置时间是28800（8小时）意味着，超过这个时间之后，MySQL 数据库为了节省资源，就会在数据库端断开这个连接，Mysql服务器端将其断开了，但是我们的程序再次使用这个连接时没有做任何判断，所以就挂了。
解决思路：
先要了解这两个参数的特性；这两个参数必须同时设置，而且必须要保证值一致才可以。
我们可以适当加大这个值，8小时太长了，不适用于生产环境。因为一个连接长时间不工作，还占用我们的连接数，会消耗我们的系统资源。
解决方法：
可以适当在程序中做判断；强烈建议在操作结束时更改应用程序逻辑以正确关闭连接；然后设置一个比较合理的timeout的值（根据业务情况来判断）
Top 10 ：can't open file (errno:24)
有的时候，数据库跑得好好的，突然报不能打开数据库文件的错误了。
解决思路：
首先我们要先查看数据库的 error log。然后判断是表损坏，还是权限问题。还有可能磁盘空间不足导致的不能正常访问表；操作系统的限制也要关注下；用 perror 工具查看具体错误！
linux:/usr/local/mysql/bin # ./perror 24
OS error code 24: Too many open files
超出最大打开文件数限制！ulimit -n查看系统的最大打开文件数是65535，不可能超出！那必然是数据库的最大打开文件数超出限制！
在 MySQL 里查看最大打开文件数限制命令：show variables like 'open_files_limit';
发现该数值过小，改为2048，重启 MySQL，应用正常
处理方法：
repair table ；
chown mysql权限
清理磁盘中的垃圾数据
Ⅳ Web应用常见的安全漏洞有哪些
Web应用常见的安全漏洞：
1、SQL注入
注入是一个安全漏洞，允许攻击者通过操纵用户提供的数据来更改后端SQL语句。当用户输入作为命令或查询的一部分被发送到解释器并且欺骗解释器执行非预期的命令并且允许访问未授权的数据时，发生注入。
2、跨站脚本攻击 （XSS）
XSS漏洞针对嵌入在客户端（即用户浏览器而不是服务器端）的页面中嵌入的脚本。当应用程序获取不受信任的数据并将其发送到Web浏览器而未经适当验证时，可能会出现这些缺陷。
3、跨站点请求伪造
CSRF攻击是指恶意网站，电子邮件或程序导致用户的浏览器在用户当前已对其进行身份验证的受信任站点上执行不需要的操作时发生的攻击。
4、无法限制URL访问
Web应用程序在呈现受保护的链接和按钮之前检查URL访问权限 每次访问这些页面时，应用程序都需要执行类似的访问控制检查。通过智能猜测，攻击者可以访问权限页面。攻击者可以访问敏感页面，调用函数和查看机密信息。
5、不安全的加密存储
不安全的加密存储是一种常见的漏洞，在敏感数据未安全存储时存在。用户凭据，配置文件信息，健康详细信息，信用卡信息等属于网站上的敏感数据信息。
(4)数据库开发者十大错误扩展阅读
web应用漏洞发生的市场背景：
由于Web服务器提供了几种不同的方式将请求转发给应用服务器，并将修改过的或新的网页发回给最终用户，这使得非法闯入网络变得更加容易。
许多程序员不知道如何开发安全的应用程序。他们的经验也许是开发独立应用程序或Intranet Web应用程序，这些应用程序没有考虑到在安全缺陷被利用时可能会出现灾难性后果。
许多Web应用程序容易受到通过服务器、应用程序和内部已开发的代码进行的攻击。这些攻击行动直接通过了周边防火墙安全措施，因为端口80或443（SSL，安全套接字协议层）必须开放，以便让应用程序正常运行。
Ⅳ 一般数据库中容易存在哪些问题可以通过什么途径来解决这些问题
一般数据库中容易存在四种问题，分别是：语句错误；用户进程错误；网络故障；用户错误。
语句错误：单个数据库操作（选择、插入、更新或删除）失败。可以尝试在表中输入无效的数据，与用户合作来验证并更改数据。
用户进程错误：用户非登出的异常退出用户会话异常终止程序错误导致会话结束，对于上述错误，实例后台进程 PMON 会自动回滚未提交的事务，并释放相关锁资源。
网络故障：与数据库的连接断开。通过备份监听程序、网络连接和网络接口卡可降低出现网络故障时影响系统可用性的可能性。
用户错误：用户成功完成了操作，但是操作不正确（删除了表，或输入了错误数据）。用户可能会无意删除或修改数据。如果发生这种情况， DBA 可能需要帮助用户从错误中恢，如果用户尚未提交或退出程序，则只可以回退操作。
Ⅵ 数据库访问错误,创建新记录失败
首先不是很推荐ODBC连接，需要额外配置，建议用OLEDB
你可以尝试着建立一个扩展名为udl的文件，新建一个文本文件扩展名改为udl即可。
在里面配置了数据库连接以后，再用写字板你就可以看到你直接可以用到的连接字符串了，例如
Provider=SQLOLEDB.1;Password=sa;Persist Security Info=True;User ID=sa;Initial Catalog=master;Data Source=.
Ⅶ SQL server 2005数据库有什么优点和缺点
SQL Server 2005的十大最新特性
在商界，每样东西都在竞争中争取“更好、更快、更便宜”——SQL Server 2005也提供了很多个新特性来节省精力、时间和金钱。从编程到管理能力，这个版本的SQL Server都优于其他版本的产品，并且它还对SQL Server 2000中已经存在的特性进行了加强。这里我按照它的重要程度列出前十个最重要的新特性。
1、加强的T-SQL (事务处理SQL )
T-SQL 天生就是基于集合的关系型数据库管理系统编程语言，可以提供高性能的数据访问。现在，它与许多新的特性相结合，包括通过同时使用TRY和CTACH来进行错误处理，可以在语句中返回一个结果集的通用表表达式(CTEs)，以及通过PIVOT 和UNPIVOT命令将列转化为行和将列转化为行的能力。
2、CLR(Common Language Runtime，通用语言运行时)
SQL Server 2005中的第二个主要的增强特性就是整合了符合.NET规范的语言 ，例如C#, ASP.NET 或者是可以构建对象(存储过程，触发器，函数等)的 VB.NET。这一点让你可以在数据库管理系统中执行.NET代码以充分利用.NET功能。它有望在SQL Server 2000环境中取代扩展的存储过程，同时还扩展了传统关系型引擎功能。
3、服务代理(Service Broker)
服务代理处理的是以松散方式进行联系的发送者和接收者之间的消息。一个消息被发送、处理和回答，完成整个事务。这大大扩展了数据驱动应用程序的性能，以符合工作流或者客户业务需求。
4、数据加密
SQL Server 2000没有用来在表自身加密数据的有文档记载的或者公共支持的函数。企业需要依赖第三方产品来满足这个需求。SQL Server 2005自身带有支持对用户自定义数据库中存储的数据进行加密的功能。
5、SMTP邮件
在SQL Server 2000中直接发送邮件是可能的，但是很复杂。在SQL Server 2005中，微软通过合并SMTP邮件提高了自身的邮件性能。SQL Server从此跟Outlook说“bye-bye”!
6、HTTP终端
你可以很轻松地通过一个简单的T-SQL 语句使一个对象可以在因特网上被访问，从而创建一个HTTP终端。这允许从因特网上呼叫一个简单的对象来获取需要的数据。
7、多活动结果集(Multiple Active Result Sets ，简称MARS)
多活动结果集允许从单个的客户端到数据库保持一条持久的连接，以便在每个连接上拥有超过一个的活动请求。这是一个主要的性能改善，它允许开发人员让用户在使用SQL Server工作的时候拥有新的能力。例如，它允许多个查询，或者一个查询的同时输入数据。底线就是一个客户端连接可以同时拥有多个活动的进程。
8、专用管理员连接
如果所有的内容都出错了，那么只能关闭SQL Server服务或者按下电源键。专用管理员连接结束了这种状况。这个功能允许数据库管理员对SQL Server发起单个诊断连接，即使是服务器正在出现问题。
9、SQL Server综合服务(SSIS)
SSIS已经作为主要的ETL(抽取、传输和载入)工作替代了DTS(数据传输服务)，并且随着SQL Server免费发布。这个工具，从SQL Server 2000开始被完全重新编写，现在已经拥有了很大程度的灵活性，来满足复杂的数据移动需求。
10、数据库镜像
我并没有指望这个功能会在11月份的RTM 中随着SQL Server 2005一起发布，但是我认为这个特性具有很大的潜力。数据库镜像是本地高可用性能力的扩展。所有，仍然在对更多的细节进行调整……那么现在，祝福吧。
还有两项技术不能在SQL Server 2005的前十列表中遗漏的是它的分析服务和报告服务。虽然SQL Server 2005没有介绍其中的任何一项，但是将它们整合进了SQL Server综合服务之中，以求微软的核心商务智能套件的完美。这些技术对于商务智能的成功至关重要。学习新的特性，以及企业如何在实际项目中实现它。
Ⅷ 数据库连接失败的原因
问题一：电脑显示连接数据库失败怎样回事 测试连接数据库不成功，在保证连接服务器设置对话框内各项内容填写正确的条件下。1般出现毛病提示的缘由有以下几种情况：1、首先看服务器电脑有无关闭WINDOWS防火墙或瑞星的防火墙2、局域网不通局域网不通就是局域网内各电脑间没有到达不需要用户名和密码的访问，就是不能相互访问同享文件，可以通过计算机间能否相互访问同享文件来判断局域网是不是畅通。方法在“网上邻居”的地址栏中输入“\\”加上要访问计算机的“记算机名称或是本地ip地址”然后链接（例如\\192.168.0.1），可以访问说明局域网畅通3、数据库服务没有启动如果是数据库没有运行，软件测试连接一样也会出现毛病提示。可以在开始菜单------程序----启动------ServiceManager或是在开始菜单----运行----输入cmd------回车-----在出现黑屏界面的光标处输入netstartMSSQLSERVER----回车如果出现提示为“要求的服务器已启动”，说明数据库已在运行了；“服务名无效”说明输入的命令不正确；“没法启动数据库服务“说明数据库文件被破坏或是其他缘由造成数据库服务没法启动。 查看原帖>>
问题二：SQL 数据库连接服务器失败 由以下几个原因：
1.数据库引擎没有启动
有两种启动方式：
(1)开始->程序->Microsoft SQL Server 2008->SQL Server 2008外围应用配置器,在打开的界面单击服务的连接的外围应用配置器,在打开的界面中找到Database Engine,单击服务,在右侧查看是否已启动,如果没有启动可单击启动,并确保启动类型为自动,不要为手动,否则下次开机时又要手动启动；
(2)可打开:开始->程序->Microsoft SQL Server 2008->配置工具->SQL Server Configuration Manager,选中SQL Server 2008服务中SQL Server(MSSQLSERVER) ,并单击工具栏中的启动服务按钮把服务状态改为启动；
使用上面两种方式时,有时候在启动的时候可能会出现错误[/b],不能启动,这时就要查看SQL Server 2008配置管理器中的SQL Server 2008网络配置->MSSQLSERVER协议中的VIA是否已启用,如果已启用,则把它禁止.然后再执行上述一种方式操作就可以了。
2.进行远程连接时,是否已允许远程连接.
SQL Server 2008 在默认情况下仅限本地连接.我们可以手动启用远程连接.在上面第一种方式中,找到Database Engine,单击远程连接,在右侧将仅限本地连接(L)改为本地连接和远程连接(R),并选中同时使用TCP/IP和named pipes(B).
3.如果是远程连接,则还要查看连接数据库的语句是否正确,登录账户是否正确,密码是否正确等.
我在一次局域网内连接数据库时,就要因为连接字符串出了问题,在局域网内一台机子连接另一台机子上数据库时,把Data Source=装有数据库的另一台机子的IP.我在连接数据库时总是出现上面的错误,查了好长时间,后来发现,IP没有正确到传到连接字符串,原来我在连接时,使用的是本地,即127.0.0.1,输入的IP没有传到连接字符串
问题三：数据库连接失败 数据库连接失误的话，通常应该是以下的几个原因：
1，没有数据库驱动包（jar)
2，如果驱动有了的话，那么记得把这个包要放到你的classpath所能识别的目录下面去。
3，如果1，2都没问题，那么是否你的数据库连接账号不对？检查你的DB名，User,Password是偿正确。
4，如果以上都没有问题，从你的程序来看是要连接SQLServer, 那么记得将SQLServer的SP3补丁打上，否则是会有连接问题存在。
如果以上都无法连接成
问题四：连接数据库错误，是什么原因 你没有说清楚是什么软件，如果软件需要连接远程数据库的话，如果远程服务器上面的sql没有启动，或者远程服务器运行不正常，都可能出现这个提示 如果连接是你本机的数据库，那你检查你本机数据库有没有启动，
问题五：为什么数据库连接失败 10分 数据库连接失败的原因
悬赏分：20 - 离问题结束有一天22小时
使用Dreamweaver的生产基地，我用aspvb的连接OLE DB访问数据库出现HTTP404错误，说，服务器没有测试服务器上运行，还有就是为网站指定的测试服务器没有被映射到，确保图像的URL前缀的根，这是它;我用aspvbscript的NET开发环境是不是 BR />哦，你不能做到这一点，下一步去哪里，希望了解能告诉我
...我不明白...离开
得分。
问题六：数据库链接失败怎么办 一般来说，要查如下步骤：
1. 确认数据库是否允许远程连接
2. 确认数据库服务是否正常启动
3. 确认数据库服务器的防火墙开通
4. 确认客户端到服务器网络畅通
5. 确认连接字符串正确，包括：主机名\实例名，端口
6. 确认数据库是否允许混合登录方式
问题七：数据库链接失败怎么办 如果你是自己的服务器，请先检查用户名、密码是否完全正确如果你是空间用户，请查看数据库IP和空间IP是否一致，如果不一致，数据库主机：localhost这里请填写数据库的IP，然后检查用户名和密码是否完全正确
问题八：thinkcms数据库连接失败什么原因 应该是ODBC没有配置好,在控制面板中,找[数据源]设置, 在里面配置好要连接数据库的ODBC源,这样才能连接成功.有错误提示的话,才能更准确的找原因.
问题九：易语言SQL数据库连接失败的原因 数据库连接1.连接SQLServer()命令的提示如下：
调用格式： 〈逻辑型〉 对象．连接SQLServer （文本型 服务器名，文本型 数据库名，文本型 用户名，文本型 密码） - 数据库操作支持库->数据库连接
英文名称：ConnectSQLServer
连接SQL Server数据库，如果连接成功返回真，失败返回假。本命令为初级对象成员命令。
参数的名称为“服务器名”，类型为“文本型（text）”。本参数提供 SQL SERVER 服务器名。
参数的名称为“数据库名”，类型为“文本型（text）”。
参数的名称为“用户名”，类型为“文本型（text）”。
参数的名称为“密码”，类型为“文本型（text）”。
如果返回为假，那么你要检查服务器ip或者名称是否正确，用户名和密码是否填写对了。你先用一个sql客户端来登陆sql服务器看看，如果使用你代码里面的服务器ip，用户名和密码有错误则是你的参数填写问题了。你先检查这个吧。
Ⅸ 软件处理差
尽管自编码有了一些进展，但现在开发软件主要仍然得靠人工。
然而，人非圣贤，孰能无过？因此，我们可以得到一个合理的推测：由人生产出来的产品和服务，必然包含某种形式的缺陷。所以，软件缺陷不可避免，并且是软件开发过程的固有部分。
软件缺陷是逻辑或配置上的错误，会导致系统产生我们不期望的行为。
软件应用程序中的一些主要和常见缺陷包括业务逻辑错误、复杂性问题、文件处理问题、封装问题、数据验证问题、身份认证和授权错误。
常见弱点枚举 (CWE) 清单描述了常见的软件和硬件弱点，会导致安全方面的相关问题。 该清单对可能存在的软件弱点进行了全面分类。
在业务研发过程中，我们通常通过比较内部质量和风险指标以及对需求、规范、标准和截止日期等方面的遵守程度，来衡量和评估软件质量等级的可接受度。
因此，我们应该可以得到这样一个结论：软件质量是主观的，受业务承诺、高级管理人员的参与情况和组织文化的影响。
软件开发中一个重要的关注点涉及到在预算、进度、范围、质量和安全性这些方面之间保持适当的平衡。一个方面的变化会影响其他方面。虽然都不希望改变计划，但这在软件开发生命周期中并不少见。这些场景反映了组织为了控制预算和进度，不得不在软件质量和安全性方面做出妥协。
软件质量并不总是软件的安全性指标。软件安全性的衡量标准，是在测试期间和生产部署之后发现的漏洞数量。软件漏洞是一类软件缺陷，潜在的攻击者经常利用这些漏洞，绕过授权，访问计算机系统或执行操作。有时，授权的用户也会出于恶意，利用系统中这些未修补的已知漏洞。
这些用户还可能会输入不能通过校验的数据，无意中利用了软件漏洞，从而损害数据完整性和使用这些数据的功能的可靠性。对漏洞的利用会针对下面三个安全支柱中的一个或多个：机密性、完整性和可用性，它们通常称为 CIA 三元组。
机密性指保护数据在未经授权时不会被泄漏；完整性指保护数据在未经授权时不会被修改，以保证数据的真实性；可用性指系统在需要时可供授权用户使用，并拒绝未经授权的用户访问。了解软件错误和漏洞之间的区别，是为创建安全的软件和及时减少缺陷和漏洞的整体战略的关键。
软件漏洞
现在已公布的漏洞利用行为，以及OWASP十大、MITRE常见漏洞和暴露 (CVE) 列表、美国国家漏洞数据库和其他来源提供的见解都在讲软件漏洞。总体而言，这些信息强调了技术创新如何打破了所需的平衡，我们可以根据这些信息采取更有效的措施，在产品部署之前更好地检测和减少软件漏洞。
软件安全瑕疵越来越多，影响最大的因素是我们对软件安全性不思进取的态度、在软件安全性方面缺乏有效的最佳实践、软件开发人员和潜在攻击者之间的知识差异以及不安全的遗留软件。
由于威胁在不断变化，因此，在安全方面与时俱进的态度对于达成软件安全性很有必要。组织在开发和部署软件时，如果对安全的态度原地踏步，有可能会把内部合规跟有效、安全的软件开发周期过程混为一谈；对不断发展的威胁向量认识不足；从而无意中增加客户在各方面的风险。安全策略一成不变，只依赖内部合规来证明开发的软件很安全，这是短视的行为。
随着时间的推移，这种依赖性将导致利益相关者对组织开发安全软件的能力产生盲目的信心，并降低软件开发团队充分审查和应对不断变化的威胁的能力。若我所料不差，这些组织很可能没有有效的补丁管理程序，也没有在产品或解决方案实施过程中集成软件安全方面的设计原则。他们也不太可能添加安全相关场景的测试套件，或将软件安全的最佳实践纳入软件开发流程。
想要研发安全的软件，在研发生命周期中就应该应用软件安全方面的最佳实践。最佳实践涵盖安全设计原则、编码、测试、工具以及针对开发人员和测试人员的培训，有助于在将产品和解决方案部署到生产环境之前主动检测和修复漏洞。在合适的情况下，应用“故障安全”、“最小权限”、“深度防御”和“职责分离”等安全设计原则，可以增强应用程序的安全性。此外，还必须优先对开发人员和测试人员进行软件安全性方面的常规培训。
软件开发人员和潜在攻击者之间的知识差距正在扩大。这种现象的原因不尽相同，其中一些原因是心态、主要关注领域不同和缺乏学习机会。此外，一些软件开发人员对系统妥协持零和态度。这种心态与深度防御的安全设计原则背道而驰，并认为网络和设备漏洞实际上是“天国的钥匙”事件（译注：keys-to-the-kingdom，基督教典故，此处是指通过漏洞获得极大权限是漏洞发现者应得的）。因此，他们认为试图尽量减少妥协是徒劳的。有许多被爆出来的系统数据泄露事件，正是这种心态引发的后果，它们因缺少安全性或分层安全性不足，导致未加密的个人数据被盗。
这种“零和”心态，无意中助长了潜在攻击者通过各种技术深入到网络中进一步破坏生态系统的能力，从而可能获得对包含个人和业务数据的其他系统的访问权限。仔细审查代码是常见的深度防御措施，但一些软件开发人员未能有效利用。这些开发人员完全依赖自动代码扫描工具，而没有审查代码，或者只是粗略地审查代码。使用自动代码扫描工具并仔细审查代码才是一种有效的深度防御策略，可以在解决方案或产品部署到生产环境之前检测出漏洞。
软件开发人员和潜在攻击者有不同的优先级和重点领域。软件开发人员的重点领域包括实现业务逻辑；修复软件缺陷以满足质量要求；确保他们实施的功能或解决方案满足内部实用性、可用性和性能指标或服务水平协议 (SLA) 中的指标。显而易见，软件开发人员会在其主要关注领域获得专业知识。而潜在攻击者主要关注领域包括系统和软件行为分析，他们不断磨练技能以增加收入、满足好奇心、实现工具集、侦察和探索。所以同样地，潜在攻击者在其关注领域里也能获得专业知识。
潜在攻击者和软件开发人员之间的技能差异，让组织需要在软件安全方面持续地对软件开发人员进行培训。软件开发人员还必须了解当前的和不断拓展的攻击向量，并了解软件攻击面的概念，以避免在软件实现和修改过程中误入雷区。此外，软件开发人员必须转变观念，将软件安全原则和最佳实践纳入到软件开发生命周期中，它们与功能实现具有同等优先级。
在开发现在被称为“遗留”软件的那些年里，功能实现通常有最高优先级。对于许多软件供应商而言，软件安全跟功能的优先级不同，而且不是软件开发流程的一部分。在这种优先级安排以及威胁形势不断增长的长期影响下，其结果就是现在“遗留”软件中那些漏洞会被人发现和利用。为什么优先考虑功能实现，原因各不相同。
竞争、上市时间问题以及对软件安全缺乏关注，是组织不能遵循软件安全最佳实践和维持软件安全开发流程的主要原因。某些组织为了更好地保护“遗留”软件，给它们分配了资金和资源，在所需功能的实现上做出牺牲；并且由于持续关注在“遗留”软件的保护上，可能会丧失潜在的竞争优势。而其他组织通过检查软件漏洞来主动评估其“遗留”系统。尽管如此，在代码库被完全修补、升级到最新最安全或被废弃之前，遗留软件都将是漏洞利用方面的沃土。
结论
软件是潜在攻击者最常用的攻击媒介之一。因此，许多组织意识到，为了实现和维护安全的软件开发流程和基础架构，尽职尽责的调查非常重要。这些组织独立而又协同地为推进网络和软件安全领域的防御策略做出贡献。企业贡献包括：创建描述网络攻击阶段的安全模型和框架（例如洛克希德马丁公司的网络杀伤链），从而使组织能够规划相应的缓解措施；设立赏金计划，奖励查找漏洞，让安全研究人员和其他人可以因发现可利用的软件缺陷而挣到钱；对开源网络安全工具集的贡献；编写应用程序安全白皮书，描述最佳实践并促进软件安全向开发-安全-运维（DevSecOps）自然过渡。
不断发展的软件攻击向量使得我们不可能在生产部署之前消除所有软件漏洞。尽管如此，软件开发人员还是必须持续学习软件安全开发。也有人正关注于使用机器学习来检测软件漏洞，这将有助于更快、更有效地检测软件漏洞。然而，这种在专业领域采用机器学习的结果是否符合预期，目前还不确定。与此同时，各组织还是必须继续在同一战线上持续投入，共同抗衡潜在攻击者。
Ⅹ 数据库连接不成功，错误号：-2147024770，错误描述：automation 错误。
关于Automation错误的成因也是多方面的，最多的是支持软件如：WINDOWS文件、系统控件等，都有可能导致问题的出现。当然，K/3自身的问题也存在。Automation错误，是系统无法捕获的错误，根据以前遇到此问题的经验，通常有以下几种可能：1、客户端的MDAC程序出现问题，通过安装MDAC2.8来解决；2、服务器的MSDTC没有正常启动，或启动用户的权限有问题，请检查组件服务中的MSDTC并使用具有启动权限的用户来启动；3、客户端的分布式DCOM没有正常启动，请检查客户端的DCOM配置属性中是否选择上“在本机启用分布式COM”选项。4、客户端或服务器中安装了相应的防火墙，截断了客户端与服务器的DCOM访问，比如XPSP2的内置防火墙设置、个人防火墙软件关闭了135和1024以上的端口，都会造成此问题。5、客户端或服务器安装某防病毒软件与K3的DCOM访问存在冲突，如瑞星等。6、客户端的组件没有正常注册，请使用TS0026补丁工具进行注册，下载地址： http://www.kingdee.com:8080/download/agentdown/tech/ts0026.rar7、我们所遇到的多是在卸载其他软件后出现的（如用友的软件，等等），估计很可能是系统文件或公用文件受到损坏所致。所以也建议朋友们尽量保持系统文件的清洁，防止卸载文件导致错误。