安安 - 数据库
type: channel
link: https://blog.90.vc/tag/%E6%95%B0%E6%8D%AE%E5%BA%93/
items: 获取HeidiSQL保存的密码
items: Kubernetes 内部组件工作原理
items: RAID5 真的安全吗
items: Oracle数据库RAC安装部署
items: Cache 和 Buffer 有什么区别？
items: CentOS7 编译安装 mariadb
items: PHP通过localhost无法连接MySQL数据库的解决
items: java程序连oracle数据库频繁出现Connection reset问题

获取HeidiSQL保存的密码
type: item
date: 2020-05-09T05:40:00+00:00
description: 今天在使用一个数据库时一是半会想不起来数据库的密码了，后来想起来在客户端工具heidisql上有保存过密码，下面讲解如何获取heidisql保存的密码。HeidiSQL是一款开源的SQL管理工具，用于管理MYSQL,MSSQL 等数据库，很多管理工具都会把密码存在本地，HeidiSQL也是如此，但是只是经过非常简单的编码，解密的过程如下。使用的是版本是HeidiSQL_11.0_64_Portable,配置会存在软件目录下的portable_settings.txt中,如果是安装的版的话，HeidiSQL安装版会配置信息存在以下注册表中：HKEY_CURRENT_USER\Software\HeidiSQL\密码会保存在以下节点下面。HKEY_CURRENT_USER\Software\HeidiSQL\Servers打开portable_settings.txt可以看到配置文件中有以下这样的ip 密码之类这样的信息HeidiSQL配置文件节选:Servers\192.168.1.1\SessionCreated<|||>1<|||>2020-04-23 09:11:48 Servers\192.168.1.1\Host<|||>1<|||>192.168.1.1 Servers\192.168.1.1\WindowsAuth<|||>3<|||>0 Servers\192.168.1.1\CleartextPluginEnabled<|||>3<|||>0 Servers\192.168.1.1\User<|||>1<|||>root Servers\192.168.1.1\Password<|||>1<|||>6A6A6A9 Servers\192.168.1.1\LoginPrompt<|||>3<|||>0 Servers\192.168.1.1\Port<|||>1<|||>3306 Servers\192.168.1.1\NetType<|||>3<|||>0 Servers\192.168.1.1\Compressed<|||>3<|||>0 Servers\192.168.1.1\LocalTimeZone<|||>3<|||>0 Servers\192.168.1.1\QueryTimeout<|||>3<|||>30 Servers\192.168.1.1\KeepAlive<|||>3<|||>20 Servers\192.168.1.1\FullTableStatus<|||>3<|||>1 Servers\192.168.1.1\Databases<|||>1<|||> Servers\192.168.1.1\Library<|||>1<|||>libmysql-6.1.dll Servers\192.168.1.1\Comment<|||>1<|||> Servers\192.168.1.1\StartupScriptFilename<|||>1<|||> Servers\192.168.1.1\TreeBackground<|||>3<|||>536870911 Servers\192.168.1.1\SSHtunnelHost<|||>1<|||> Servers\192.168.1.1\SSHtunnelHostPort<|||>3<|||>22 Servers\192.168.1.1\SSHtunnelUser<|||>1<|||> Servers\192.168.1.1\SSHtunnelPassword<|||>1<|||>1 Servers\192.168.1.1\SSHtunnelTimeout<|||>3<|||>4 Servers\192.168.1.1\SSHtunnelPrivateKey<|||>1<|||> Servers\192.168.1.1\SSHtunnelPort<|||>3<|||>3307 Servers\192.168.1.1\SSL_Active<|||>3<|||>0 Servers\192.168.1.1\SSL_Key<|||>1<|||> Servers\192.168.1.1\SSL_Cert<|||>1<|||> Servers\192.168.1.1\SSL_CA<|||>1<|||> Servers\192.168.1.1\SSL_Cipher<|||>1<|||> Servers\192.168.1.1\ServerVersionFull<|||>1<|||>5.7.29 - MySQL Community Server (GPL) Servers\192.168.1.1\ConnectCount<|||>3<|||>7 Servers…

Kubernetes 内部组件工作原理
type: item
date: 2020-03-31T14:32:00+00:00
description: 翻译自:https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca原作者：Joe Beda (Dad of two. CTO of Heptio. Started Google Compute Engine, Kubernetes and Google Container Engine.)本篇文章讲述了Kubernetes内部组件的工作原理，及创建POD的流程。如果你是运维人员或者是Kubernetes的使用者，你可以不需要知道Kubernetes的内部工作原理，但是如果你想理解Kubernetes内部的工作原理，这篇文章非常适合你。读这篇文章的前提是，你已经大致了解并会运用Kubernetes。这篇文章不会去描述什么是Kubernetes及其组件（如：Pod, Node, Kubelet）。 本篇将讨论Kubernetes核心组件及这些核心组件是如何让Kubernetes 对"爵士乐即兴演奏"。通常将像Kubernetes这样的通用系统称为容器的 "管弦乐编排"。但是管弦乐编排，必须有一个预先计划的指挥家。因此，这并不是Kubernetes的一个好的描述。相反，Kubernetes更像是爵士乐即兴演奏，有一系列演员互相配合协调完成演奏。接下来，开始介绍每个核心组件的功能。然后将看一个典型的调度和启动一个Pod的流程。1. Datastore: EtcdEtcd是Kubernetes的存储状态的数据库。虽然Kubernetes系统中有重要的内存缓存，但Etcd被认为是记录系统状态。Etcd的快速总结：它是一个集群分布式数据库，它可以提供分布式数据的一致性。这类的系统（如Zookeeper, Consul）是在 Google开发的chubby系统之后形成的，这些系统也称为"锁服务器"，因为他们可以实现分布式锁。Etcd和chubby的数据模型是一个简单的层次化的Key，并存储了简单的非结构化value，这看起来像是一个文件系统。有意思的是，在Google, chubby 被频繁用于为实现访问本地文件和对象存储的功能的抽象文件接口。然而，分布式数据库的高度一致性，提供了数据的严格写入顺序并允许client原子性的对数据做更新操作。可靠的系统的状态管理是任何系统中非常困难的一件事情。在分布式系统中，它是更加困难的，因为它引入了一致性算法，如raft或paxos。通过使用etcd，Kubernetes可以专注系统的其他部分。Etcd的watch机制是Kubernetes工作的关键。系统允许client去执行轻量级的对于Key值变化事件的订阅。当要watch的数据发生变化时, client会立即得到通知。这可以用作分布式系统组件之间的协调机制。 一个组件一旦写入etcd，其他组件可以立即对该变化作出反应。Etcd的消息机制正好和PubSub消息队列机制相反。在许多消息队列系统系统中，topic不存储真正的用户数据，但发布到这些topic的消息含有丰富的数据。对于像Etcd这样的系统，Key（类似于主题）存储了真实的数据而消息（数据变化通知）不含独特的丰富消息。换句话说，对于消息队列来说，topic很简单，而像Etcd则正好相反。（译者认为此处概括的非常准确）2. Policy Layer: API ServerKubernetes的核心组件是API Server，它是Kubernetes系统和Etcd直接对话的唯一组件。实际上，etcd是API server的实现细节，理论上也可以用其他分布式存储系统来支持Kubernetes.API server是一个策略组件，提供对Etcd的过滤访问。它的作用本质上是相对通用的，目前正在被分解处理。因此，API Server也可以用于其他系统的控制平面。API server的主要货物是资源，通过暴露简单的REST API 向外提供服务。这些资源有一个标准结构可以实现一些扩展功能。无论如何，API Server，允许各类组件创建，读取，写入，更新，和监视资源。API Server的具体的功能：认证和授权。Kubernetes有一个可插拔的认证系统。有一些内置的用户认证机制和授权这些用户访问资源。此外，还有一些方法可用于向外部服务提供这些服务。这种可扩展性是Kubernetes构建的核心功能。API Server运行一组可以拒绝或修改请求的准入控制器。 这些允许策略被应用并设置默认值。 这是确保在API Server客户端仍在等待请求确认时进入系统的数据有效性的关键。 虽然这些准入控制器目前正在编译到API Server中，但目前正在进行的工作是使其成为另一种可扩展性机制。API Server 有助…

RAID5 真的安全吗
type: item
date: 2020-03-02T14:01:00+00:00
description: 转载自知乎一句话结论：现代大容量硬盘组成的RAID 5单盘故障后，重建失败的概率相当高，不可忽略；但数据本身还是基本安全的（会丢失部分文件），只是可能需要一个比较麻烦的恢复方案。楼上包括高赞回答在内一堆说两个硬盘同时坏的，要加一个热备盘的，都是没仔细看过问题里面的链接就回答的。在回答问题的现在，这个链接失效了，但网上还是有人转载过的，例如这篇[1]：DBA亲，你们的RAID5阵列有保障吗？marbury关注0人评论10546人阅读2014-02-21 10:30:24 该文章主要整理论坛内容。（论坛地址：http://bbs.et8.net/bbs/showthread.php?t=1026112）很多人遇到过服务器RAID5挂掉，往往掉一个盘后，第二个盘也立刻挂掉。引用：RAID 5也是以数据的校验位来保证数据的安全，但它不是以单独硬盘来存放数据的校验位，而是将数据段的校验位交互存放于各个硬盘上。这样，任何一个硬盘损坏，都可以根据其它硬盘上的校验位来重建损坏的数据。硬盘的利用率为n-1。如果挂掉两个盘，数据就玩完了。 理论上两个硬盘同时失效的概率是很低的，但为什么会这样呢？ 引用：从数学角度说，每个磁盘的平均无故障时间 (MTBF) 大约为 50 万至 150 万小时(也就是每 50～150 年发生一次硬盘损坏)。实际往往不能达到这种理想的情况，在大多数散热和机械条件下，都会造成硬盘正常工作的时间大幅减少。考虑到每个磁盘的寿命不同，阵列中的任何磁盘都可能出现问题，从统计学角度说，阵列中 N 个磁盘发生故障的机率比单个磁盘发生故障的机率要大 N 倍。结合上述因素，如果阵列中的磁盘数量合理，且这些磁盘的平均无故障时间 (MTBF) 较短，那么在磁盘阵列的预期使用寿命过程中，就很有可能发生磁盘故障(比方说每几个月或每隔几年就会发生一次故障)。 两块磁盘同时损坏的几率有多大呢(“同时”就是指一块磁盘尚未完全修复时另一块磁盘也坏掉了)?如果说 RAID 5 阵列的MTBF相当于MTBF^2，那么这种几率为每隔10^15个小时发生一次(也就是1万多年才出现一次)，因此不管工作条件如何，发生这种情况的概率是极低的。从数学理论角度来说，是有这种概率，但在现实情况中我们并不用考虑这一问题。不过有时却是会发生两块磁盘同时损坏的情况，我们不能完全忽略这种可能性，实际两块磁盘同时损坏的原因与MTBF基本没有任何关系。 对这种情况来说，这里首先要引入一个一般人不常接触到的概念：BER 硬盘误码率,英文是BER(Bit Error Rate),是描述硬盘性能的一个非常重要的参数,是衡量硬盘出错可靠性的一个参数。这个参数代表你写入硬盘的数据，在读取时遇到不可修复的读错误的概率。从统计角度来说也比较少见，一般来说是指读取多少位后会出现一次读取错误。 随着硬盘容量增加，驱动器读取数据的误读率就会增加，而硬盘容量暴涨，误码率的比例一直保持相对增加。一个1TB的驱动器是需要更多读取整个驱动器，这是在RAID重建期间发生错误的概率会比300G 驱动器遇到错误的几率大。 那这个错误的几率到底有多大呢？或者说，我们写入多少GB数据，才会遇到1byte的读取错误呢？看这篇文章：http://lenciel.cn/docs/scsi-sata-reliability/对于不同类型的硬盘（以前企业级、服务器、数据中心级硬盘用SCSI/光纤，商用、民用级别是IDE；现在对应的则是SAS/SATA； 他们的MRBF（平均无故障时间）是接近的，但是BER便宜的SATA硬盘要比昂贵的SCSI硬盘的误码率（BER）要高得多。 也就是说，出现某个sector无法读取的情况，SATA要比SCSI严重得多。具体区别在固件上：遇到读取不过去，或者写入不过去的坏道时，家用硬盘会花费1分钟以上的时间去尝试纠正错误，纠正不了就直接用备用扇区代替，这个时间超过阵列控制器能容忍的限度，所以遇到这种情况直接掉盘；企业级的磁盘会把这项工作放在后台进行，不需要停顿1分钟左右的时间，从而不影响阵列运行。在BER 硬盘误码率上没有任何区别。 按照文中的计算，一个1TB的硬盘，通常你无法读取所有sector的概率达到了56%，因此你用便宜的大容量SATA盘，在出现硬盘故障的情况下重建RAID的希望是：无法实现。 用1TB的SATA硬盘做RAID5的话，当你遇到一个硬盘失效的情况，几乎剩下的两个以上硬盘（RAID5最少组合是3个）铁定会遇到一个硬盘读取错误，从而重建失败。 所以，以前小硬盘做RAID5，基本很少遇到同时挂掉两个盘的情况；现在硬盘大了，出问题的概率也越来越大了。 对于跑RAID的用户，对整个硬盘进行读取的事情经常发生。即使系统足够和谐，知道不对你报告那些出现在你从不读取的文件中的坏道，但是也只是略过了…

Oracle数据库RAC安装部署
type: item
date: 2020-03-01T10:05:00+00:00
description: Oracle RAC数据库安装实施文档一 数据库RAC安装规划1.1. 集群节点及实例节点名称实例名称数据库名称RAMOSnode1orcl1orcl16GRHEL 6.9 64bitnode2orcl2orcl16GRHEL 6.9 64bit1.2. 网络配置标识名称类型IP地址解析node1 Publicnode1public172.16.2.1/etc/hostsnode1 privatenode1-privprivate192.168.1.1/etc/hostsnode1 VIPnode1-vipVirtual172.16.2.11/etc/hostsnode2 Publicnode2public172.16.2.2/etc/hostsnode2 privatenode2-privprivate192.168.1.2/etc/hostsnode2 Vipnode2-vipVirtual172.16.2.12/etc/hostsScan vipscan-clusterVirtual172.16.2.13/etc/hosts1.3. Oracle软件部分Software CompanetnsGrid InfrstructureOracle RAC操作系统用户gridOracle主要属组oinstalloinstall辅助属组dbadbaHome目录/home/grid/home/oracleOracle Base/u01/app/grid/u01/app/oracleOracle Home/u01/app/11.2.0/grid/u01/app/oracle/product/11.2.0/db_1软件版本Oracle 11.2.0.4 1.4. 用户组规划GroupNameGroup ID说明HOSToinstall2001Oracle清单和软件所有者node1 node2dba2002数据库管理员 1.5. 用户规划UserIDPrimaryGroupGroup说明HOST默认口令2001gridoinstall dbaOracle Cluster用户node1 node2oracle2002oracleoinstall dbaOracle数据管理员node1 node2oracle1.6. 存储规划存储建议采用RAID 10的存储方式。存储项文件系统大小ASM磁盘组冗余方式OCR/VotingASM2G*3OCRVTNormalDatafile/ArchivelogASM900GDATAExternal说明：一般情况下存储会做Raid，有磁盘级别的镜像和保护，因此建议OCR磁盘组使用Normal方式镜像，同时归档和数据库磁盘为外部冗余方式。二 安装前准备配置2.1 检查两台机器物理内存[root@ node1 ~]# top | grep Mem Mem: 16170748k total, 15670912k used, 499836k free, 278212k buffers [root@ node2 ~]# top | grep Mem Mem: 16170748k total, 15658388k used, 512360k free, 276632k buffers 2.2 检查两台机器swap和/tmp[root@ node 1 ~]# top | grep Swap Swap: 16777212k total, 40868k used, 16736344k free, 12668624k cached [root@ node 2 ~]# top | grep Swap Swap: 16777212k total, 40868k used, 16736344k free, 12668624k cached [root@ node1 ~]# df -h /tmp/ Filesystem Size Used Avail Use% Mounted on /dev/sda3 28G 3.8G 22G 15% / [root@ node 2 ~]# df -h /tmp/ Filesystem Size Used Avail Use% Mounted on /dev/sda3 28G 3.8G 22G 15% /2.3 验证操作系统版本和bit[root@ node1 ~]# uname -a Linux node2 2.6.32-504.el6.x86_64 #1 SMP Tue Sep 16 01:56:35 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux [root@ node1 ~]# cat /etc/redhat-release Red Hat Enterprise Li…

Cache 和 Buffer 有什么区别？
type: item
date: 2019-12-19T07:57:38+00:00
description: Cache和Buffer是两个不同的概念，简单的说，Cache是加速“读”，而buffer是缓冲“写”，前者解决读的问题，保存从磁盘上读出的数据，后者是解决写的问题，保存即将要写入到磁盘上的数据。在很多情况下，这两个名词并没有严格区分，常常把读写混合类型称为buffer cache，本文后续的论述中，统一称为cache。Oracle中的log buffer是解决redo写入的问题，而data buffer cache则解决data block的读写问题。对于Oracle来说，如果IO没有在SGA中命中，都会发生物理IO，Oracle并不关心底层存储的类型，可能是一套存储系统，可能是本地磁盘，可能是RAID 10，也可能是RAID 5，可能是文件系统，也可能是裸设备，或是ASM。总之，Oracle把底层的存储系统称为存储子系统。在存储系统中，cache几乎无处不在（在后面的论述中，我们统称为cache），文件系统有cache，存储有cache，RAID控制器上有cache，磁盘上也有cache。为了提高性能，Oracle的一个写操作，很有可能写在存储的cache上就返回了，如果这时存储系统发生问题，Oracle如何来保证数据一致性的问题。Oracle数据库最重要的特性是：Write ahead logging，在data block在写入前，必须保证首先写入redo log，在事务commit时，同时必须保证redo log被写入。Oracle为了保证数据的一致性，对于redo log采用了direct IO，Direct IO会跳过了OS上文件系统的cache这一层。但是，OS管不了存储这一层，虽然跳过了文件系统的cache，但是依然可能写在存储的cache上。一般的存储都有cache，为了提高性能，写操作在cache上完成就返回给OS了，我们称这种写操作为write back，为了保证掉电时cache中的内容不会丢失，存储都有电池保护，这些电池可以供存储在掉电后工作一定时间，保证cache中的数据被刷入磁盘，不会丢失。不同于UPS，电池能够支撑的时间很短，一般都在30分钟以内，只要保证cache中的数据被写入就可以了。存储可以关闭写cache，这时所有的写操作必须写入到磁盘才返回，我们称这种写操作为write throuogh，当存储发现某些部件不正常时，存储会自动关闭写cache，这时写性能会下降。RAID卡上也有cache，一般是256M，同样是通过电池来保护的，不同于存储的是，这个电池并不保证数据可以被写入到磁盘上，而是为cache供电以保护数据不丢失，一般可以支撑几天的时间。还有些RAID卡上有flash cache，掉电后可以将cache中的内容写入到flash cache中，保证数据不丢失。如果你的数据库没有存储，而是放在普通PC机的本地硬盘之上的，一定要确认主机中的RAID卡是否有电池，很多硬件提供商默认是不配置电池的。当然，RAID卡上的cache同样可以选择关闭。磁盘上的cache，一般是16M-64M，很多存储厂商都明确表示，存储中磁盘的cache是禁用的，这也是可以理解的，为了保证数据可靠性，而存储本身又提供了非常大的cache，相比较而言，磁盘上的cache就不再那么重要。SCSI指令中有一个FUA(Force Unit Access)的参数，设置这个参数时，写操作必须在磁盘上完成才可以返回，相当于禁用了磁盘的写cache。虽然没有查证到资料，但是我个人认为一旦磁盘被接入到RAID控制器中，写cache就会被禁用，这也是为了数据可靠性的考虑，我相信存储厂商应该会考虑这个问题。至此，我们可以看到Oracle的一个物理IO是经历了一系列的cache之后，最终被写入到磁盘上。cache虽然可以提高性能，但是也要考虑掉电保护的问题。关于数据的一致性，是由Oracle数据库，操作系统和存储子系统共同来保证的。

CentOS7 编译安装 mariadb
type: item
date: 2019-03-11T07:27:00+00:00
description: 编译参数cmake . -DCMAKE_INSTALL_PREFIX=/data/mysql -DMYSQL_DATADIR=/data/mysql/data -DSYSCONFDIR=/etc -DWITHOUT_TOKUDB=1 -DWITH_INNOBASE_STORAGE_ENGINE=1 -DWITH_ARCHIVE_STPRAGE_ENGINE=1 -DWITH_BLACKHOLE_STORAGE_ENGINE=1 -DWIYH_READLINE=1 -DWIYH_SSL=system -DVITH_ZLIB=system -DWITH_LOBWRAP=0 -DMYSQL_UNIX_ADDR=/data/mysql/mysql.sock -DDEFAULT_CHARSET=utf8make && make install添加mariadb运行用户及组useradd -d /data/mysql -M -s /sbin/nologin mysql初始化数据库scripts/mysql_install_db --user=mysql --datadir=/data/mysql/data --collation-server=utf8_general_ci输出OK则成功Installing MariaDB/MySQL system tables in '/data/mysql/data' ... OK To start mysqld at boot time you have to copy support-files/mysql.server to the right place for your system PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER ! To do so, start the server, then issue the following commands: './bin/mysqladmin' -u root password 'new-password' './bin/mysqladmin' -u root -h 172-25-68-120 password 'new-password' Alternatively you can run: './bin/mysql_secure_installation' which will also give you the option of removing the test databases and anonymous user created by default. This is strongly recommended for production servers. See the MariaDB Knowledgebase at http://mariadb.com/kb or the MySQL manual for more instructions. You can start the MariaDB daemon with: cd '.' ; ./bin/mysqld_safe --datadir='/data/mysql/data' You can test the MariaDB daemon with mysql-test-run.pl cd './mysql-test' ; perl mysql-test-run.pl Please report any problems at http://mariadb.org/jira The latest information about MariaDB is available at http://mariadb.org/. You can find additional information about the MySQL part at: http://dev.mysql.com Consider joining MariaDB's strong and vibrant community: https://mariadb.org/get-involved/ You have new mail in /var/spool/mail/root 启动数据库进行mysql安全配置./bin/mysql_secure_installation

PHP通过localhost无法连接MySQL数据库的解决
type: item
date: 2018-11-02T04:54:06+00:00
description: 问题：一台服务器的PHP程序通过localhost地址无法连接数据库，但是如果设置为127.0.0.1则可以正常连接，连接其他数据库服务器也正常。MySQL的权限设置正确，且通过mysql命令行客户端可以正常连接数据库。分析：这是典型的socket没有正确设置的情况。连接MySQL数据库有两种方式：TCP/IP（一般理解的端口的那种）和Unix套接字（一般叫socket或者sock）。大部分情况下，可以用localhost代表本机127.0.0.1，但是在MySQL连接时，二者不可混用，而且MySQL中权限设置中localhost与127.0.0.1也是分开设置的。当设置为127.0.0.1时，系统通过TCP/IP方式连接数据库；当设置为localhost时，系统通过socket方式连接数据库。解决：首先要看本机MySQL的socket套接字文件在哪里，查看命令是：mysqld --verbose --help | grep socket输出结果显示套接字文件的位置，比如：这台服务器显示的是socket /var/run/mysqld/mysqld.sock然后修改php的配置文件php.ini与之对应起来就好了。找到这一项：mysql.default_socket =一般来说这一项都是空的，改成：mysql.default_socket = /var/run/mysqld/mysqld.sock这里应写上一步查询到的文件，根据你的情况设置。至此php配置就修改好了，如果是CLI（命令行）方式或者CGI方式的话，立即就生效，如果是FASTCGI方式，需要重启一下fastcgi进程。

java程序连oracle数据库频繁出现Connection reset问题
type: item
date: 2018-11-01T09:58:27+00:00
description: java项目在启动的时候，卡在数据库连接阶段，并且频繁抛出以下错误：Caused by: java.net.SocketException: Connection reset at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:1根据oracle的说明，oracle jdbc在连接时需要一些随机数来加密session。在linux系统中，随机数的产生依赖于/dev/random以及/dev/urandom两个设备。这两个设备的差异在于：/dev/random的random pool通过搜集键盘，鼠标，中断，磁盘操作等系统中断来产生随机数，因此在系统的中断数不足时，/dev/random设备会一直封锁，尝试读取的进程就会进入等待状态，直到系统的中断数充分够用, /dev/random设备可以保证数据的随机性，一般用于产生高随机性的公钥或一次性密码本。而 /dev/urandom不依赖系统的中断，它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞，但是数据的随机性也不高，属于伪随机。由于系统默认是使用/dev/random产生随机数，因此，当系统中断不足时，java程序连接oracle时便会一直等待，直到超时。侥幸的话，多尝试几次可以成功连接，而运气不好的话，只能通过重启操作系统来解决。在内网环境下，随机性要求应该不是那么严格，我们可以采用/dev/urandom来产生随机数的方法来提高程序连接，最简便的方法是将random替换为urandommv /dev/random /dev/random-bak ln -s /dev/urandom /dev/random之后再重启应用的时候，极少出现连接被reset的情况，且程序初始化的速度大大提升。