DB2数使用时提示 Connection is closed. ERRORCODE=-4470, SQLSTATE=08003是怎么回事呢，请大侠帮忙解决

用户名密码错误，输入流和输出流错误。

SQLCODE -843 SQLSTATE 08003

Explanation: Connection does not exist 说明：连接不存在。

SQLCODE -900 SQLSTATE 08003

Explanation: Application process not in a connected state 说明：应用程序不处于连接状态的过程。

根据执行次数排序

[db2inst2@localhost ~]$ grep -ni "number of executions" snapout |grep -v "=0" |sort -k 6,6rn

846: Number of executions = 306

1198: Number of executions = 117

1038: Number of executions = 43

654: Number of executions = 43

814: Number of executions = 43

扩展资料：

DB2可运行在OS/2、Windows NT、UNIX *** 作系统上，通常将运行在这些平台上的DB2产品统称为DB2通用数据库，这主要是强调这些产品运行环境类似，并共享相同的源代码。DB2通用数据库主要组件包括数据库引擎（Dalabase Engine ）应用程序接口和一组工具。

数据库引擎提供了关系数据库管理系统的基本功能，如管理数据、控制数据的访问（包括并发控制）、保证数据完整性及数据安全。所有数据访问都通过SQL接口进行。

参考资料来源：百度百科-DB2数据库

这个事情需要展开来看

很多大型企业单位为了满足业务系统的使用需要，使用很强劲的服务器主机，以大型机、小型机为主。这些机器都不使用windows系统，所以SQL Server之类的数据库没办法在这种机器上运行。Oracle、DB2、Sybase之类的是主流，这几个数据库有很强大的技术支持团队，也是受到大企业欢迎的原因。

计算机水平国外还是比较高的，所以外国软件公司开发的针对大企业的软件也都要求在这种数据库上运行。

约定俗成，微软的 *** 作系统和数据库由于不能运行在很强劲的主机上，所以只能给中小企业服务。微软系列的还有access数据库，基本上是为单机服务的。

至于MySQL基本上是为网站服务的，主要特点是免费，应用挺多，但是大企业信息化软件很少用，因为没有对应的业务支持人员，到时候出问题，找不到人，就出大事故了。

反过来再看数据库本身，都有参数说明，你仔细看看就知道了。很多小数据库本身底气就不足，并发数量、最大库文件等等参数标得很低，你说大企业动辄几T几P的数据，敢忘这种数据库上放吗？软件公司敢编写用这种数据库的软件吗？

再说说知名度，企业之间都会互相问，要是一个很小很便宜的数据库大家都用，都用得很好，市场占有率极高。自然口碑就好，大家就都用了。微软的sqlsever就是一个例子。从最开始的65基本上不能用到sql2000很成功，得到大量企业的认同，到现在出到2008版本，占有率很高了，就是口碑，可是它在大企业中使用不理想，所以还是占有中小企业。

分析这些数据库，应该多方面来看，不能只看参数，只看技术。你都分析好了，发现某个数据库不像大家说的，你能用，可是市场上找不到对应的软件，也没辙，除非你自己编写。

1、什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的 *** 作由不同的小 *** 作组成，这些小的 *** 作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小 *** 作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2、分布式事务的产生的原因

21、数据库分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个 *** 作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

22、应用SOA化

所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行 *** 作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

以上两种情况表象不同，但是本质相同，都是因为要 *** 作的数据库变多了！

3、事务的ACID特性

31、原子性（A）

所谓的原子性就是说，在整个事务中的所有 *** 作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的 *** 作都会被回滚，整个事务就像从没被执行过一样。

32、一致性（C）

事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。

33、隔离性（I）

所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。

34、持久性（D）

所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

4、分布式事务的应用场景

41、支付

最经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些 *** 作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的 *** 作必然需要引入分布式事务。

42、在线下单

买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

5、常见的分布式事务解决方案

51、基于XA协议的两阶段提交

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。

52、消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地 *** 作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下：

1、A系统向消息中间件发送一条预备消息

2、消息中间件保存预备消息并返回成功

3、A执行本地事务

4、A发送提交消息给消息中间件

通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：

步骤一出错，则整个事务失败，不会执行A的本地 *** 作步骤二出错，则整个事务失败，不会执行A的本地 *** 作步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？答案是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地 *** 作+发消息）+B系统的本地 *** 作，其中B系统的 *** 作由消息驱动，只要消息事务成功，那么A *** 作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地 *** 作，如果本地 *** 作失败，消息会重投，直到B *** 作成功，这样就变相地实现了A与B的分布式事务。原理如下：

虽然上面的方案能够完成A和B的 *** 作，但是A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。

53、TCC编程模式

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个 *** 作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

6、总结

分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力

DB2拥有悠久的历史并且被很多人认为是最早使用SQL（同样最早被IBM开发）的数据库产品。

1968:IBM 在 IBM 360 计算机上研制成功了 IMS V1，这是第一个也是最著名的和最为典型的层次型数据库管理系统。至今仍然还有企业在使用呢。

1970:这是数据库历史上划时代的一年，IBM公司的研究员EFCodd 发表了业界第一篇关于关系数据库理论的论文A Relational Model of Data for Large Shared Data Banks，首次提出了关系模型的概念。这篇论文是计算机科学史上最重要的论文之一，奠定了Codd博士关系数据库之父的地位。

1973:IBM研究中心启动了 System R 项目，研究多用户与大量数据下关系型数据库的可行性，它为 DB2 的诞生打下了良好基础。由此取得了一大批对数据库技术发展具有关键性作用的成果，该项目于1988年被授予ACM软件系统奖。

1974:IBM研究员Don Chamberlin 和 Ray Boyce 通过 System R 项目的实践，发表了论文SEQUEL：A Structured English Query Language，提出了 SEQUEL 语言，此即 SQL 语言的原型。

1975:IBM研究员Don Chamberlin 和 Morton Astrahan的论文 Implentation of a Structured English Query Language，在 SEQUEL 的基础上 描述了 SQL 语言的第一个实现方案。这也是 System R 项目得出的重大成果之一。

1976:IBM System R 项目组发表了论文A System R: Relational Approach to Database Management，描述了一个关系型数据库的原型。IBM 的研究员Jim Gray 发表了名为Granularity of Locks and Degrees of Consistency in a Shared DataBase的论文，正式定义了数据库事务的概念和数据一致性的机制。

1977:System R 原型在3个客户处进行了安装，这 3 个客户分别是：波音公 司、Pratt & Whitney 公司和 Upjohn 药业。这标志着 System R 从技术上已经是 一个比较成熟的数据库系统，能够支撑重要的商业应用了。

1979:IBM研究员Pat Selinger在她的论文Access Path Selection in a Relational Database Management System中描述了业界第一个关系查询优化器。

1980:IBM发布了 S/38 系统，该系统中集成了一个以 System R 为原型的数据库服务器。为了方便应用程序的移植，它的 API 与 S/3、S/32 的 API 一致。

1981:由于发明了关系型数据库模型，IBM 的研究员EFCodd 接受了ACM 图灵奖，这是计算机科学界的最高荣誉。Codd 博士也是继查尔斯巴赫曼（Charles W Bachman） 之后，又一位由于在数据库领域做出巨大贡献而获此殊荣的计算机科学家。

1982:IBMPC 的出现标志着 PC 产业开始孕育发展。在以后相当长的一段时间内，在各种品牌的个人电脑上标记着的IBM PC Compatible字样都见证着 IBM 在 这个领域的辉煌。

1982:IBM发布了 SQL/DS for VSE and VM 。这是业界第一个以 SQL 作为接口的商用数据库管理系统。该系统也是基于 System R 原型所设计的。

1983:IBM发布了DATABASE 2（DB2）for MVS（内部代号为Eagle）。

1986:System/38 V7 发布，该系统首次配置了查询优化器，能够对应用程序的存取计划进行优化。

1987:IBM发布带有关系型数据库能力的 OS/2 V10扩展版，这是IBM第一次把关系型数据库处理能力扩展到微机系统。这也是 DB2 for OS/2、Unix and Window 的雏形。

1988:IBM发布了SQL/400，为集成了关系型数据库管理系统的AS/400服务器提供了SQL支持。IDUG（国际DB2用户组织）组织成立。

1989:IBM定义了 Common SQL 和 IBM 分布式关系数据库架构（DRDA），并在 IBM 所有的关系数据库管理系统上加以实现。 第一届 IDUG北美大会在美国芝加哥召开。 1992:第一届 IDUG欧洲大会在瑞士日内瓦召开。这标志着 DB2 应用的全球化。

1993:

1IBM发布了DB2 for OS/2 V1（DB2 for OS/2 可以被简写为DB2/2）和 DB2 forRS/6000V1（DB2 for RS/6000 可以被简写为DB2/6000），这是 DB2 第 一次在Intel 和Unix 平台上出现。

2Louis V Gerstner 入主 IBM。

1994:

1DB2 For MVS V4 通过并行 Sysplex 技术的实现在主机上引入了分布式计算（数据共享）。

2IBM发布了运行在 RS/6000 SP2 上的 DB2 并行版 V1，DB2 从此有了能够适应大型数据仓库和复杂查询任务的可扩展架构。IBM 将 DB2 Common Server 扩展到 HP-UX 和 Sun Solaris 上。DB2 开始支持其他公司开发的 UNIX 平台。 DB2/400 集成在 OS/400 V31中发布，并且引入了并行机制、存储过程和参照完整性等机制。同时，IBM 宣布在 OS/2 和 AIX 平台上的 DB2 产品能够对多媒体数据和面向对象应用程序提供支持。

1995:

1IBM发布了 DB2 Common Server V2，这是第一个能够在多个平台上运行的对象-关系型数据库(ORDB)产品，并能够对 Web 提供充分支持。DataJoiner for AIX 也诞生在这一年，该产品赋予了 DB2 对异构数据库的支持能力。DB2 在 Windows NT 和 SINIX平台上的第一个版本（DB2 V2）发布。

2IBM发布了在 AIX 和 MVS 平台上的数据挖掘技术，用于管理大文本、图像、音频、视频和指纹信息的扩展器（Extender）以及可以对数据仓库进行可视化构造和管理的Visual Warehouse。

3IBM发布了 DB2 >

以上就是关于DB2数使用时提示 Connection is closed. ERRORCODE=-4470, SQLSTATE=08003是怎么回事呢，请大侠帮忙解决全部的内容，包括:DB2数使用时提示 Connection is closed. ERRORCODE=-4470, SQLSTATE=08003是怎么回事呢，请大侠帮忙解决、Oracle、DB2、MySQL、SQL Server、Sybase这几款数据的重点应用领域分别是哪些比如电信、互联网、银行等等、深入理解分布式事务，高并发下分布式事务的解决方案等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！