A. 数据库连接特别慢
ping一下数据库服务器，看下延时。
如果延时正常的话，然后查询下连接数，检查是不是创建了大量连接。
再没有问题就尝试sqlplus直连。正常情况数据库主机通信不是很大，一般是程序中有大量创建连接引起的。
B. SQL数据库容量大，查询速度慢，有何解决方案
首先应该确定是谁慢的，往往是程序处理方面的问题而不是数据库的问题。
程序方面应该尽可能的减少数据查询返回的内容，比如可以查询返回ID，然后再根据ID一条一条的查询具体内容，看似慢了，在数据量达的时候快很多
对于数据可以参照下面几点
1、优化SQL语句，SQL语句对查询速度影响最大
2、对于经常查询的字段作索引。但是这样会增加修改时的压力
4、优化SQLServer，比如给其分配固定的内存，预先分配查询内存，调整CPU使用率等。
5、优化硬件资源，比如使用更高的服务器或者硬盘，独立安排数据库的数据文件和索引文件，将数据文件分布于不同的物理硬盘上等等
6、考虑使用分布数据库或者对大表进行拆分
另外，2G的数据库应该不算很大了，我处理过18G的数据库，8000万条记录，查询速度可以被接受
C. SQL数据库添加记录变慢了，怎么办
1、删除日志
2、将数据表进行修正一下，每月考勤结束后，将数据移到相应的数据备份表中，这样数据表中只保留没有进行考勤汇总的数据，即当前数据。
其他，可能与你的系统设计有关。
不知你添加数据是如何添的
好像不应该用rsquery.open
而应该用：con0.execl("insert into ...."),这样是没有问题的。
D. 当数据库变慢时的解决方法有哪些
我们使用电脑和手机时候最不能忍受就是设备又卡又慢了,严重影响我们工作或者游戏体验。当数据库变慢时，我们应如何入手，下面的解决方法。
方法步骤
第一章 检查系统的状态
1.1 使用sar来检查操作系统是否存在IO问题
1.2 关注内存vmstat
1.3 找到使用资源特别大的Oracle的session及其执行的语句
1.4 查找前十条性能差的sql语句
当数据库变慢时，我们应如何入手
当应用管理员通告现在应用很慢、数据库很慢时，当Oracle DBA在数据库上做几个示例的Select也发现同样的问题时，有些时侯就会无从下手，因为DBA认为数据库的各种命种率都是满足Oracle文档的建议。实际上如今的优化己经向优化等待(waits)转型了，实际中性能优化最根本的出现点也都集中在I/O，这是影响性能最主要的方面，由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法。下面把一些实践经验与大家分享，本文测重于Unix环境。
第一章 检查系统的状态
通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲，这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。除此之外，还应观注那些占用系统资源(cpu、内存)的进程。
1.1 使用sar来检查操作系统是否存在IO问题
#sar -u 2 10 -- 即每隔2秒检察一次，共执行20次。
结果示例：
注：在redhat下，%system就是所谓的%wio。
Linux 2.4.21-20.ELsmp (YY075) 05/19/2005
10:36:07 AM CPU %user %nice %system %idle
10:36:09 AM all 0.00 0.00 0.13 99.87
10:36:11 AM all 0.00 0.00 0.00 100.00
10:36:13 AM all 0.25 0.00 0.25 99.49
10:36:15 AM all 0.13 0.00 0.13 99.75
10:36:17 AM all 0.00 0.00 0.00 100.00
其中：
Ø %usr指的是用户进程使用的cpu资源的百分比;
Ø %sys指的是系统资源使用cpu资源的百分比;
Ø %wio指的是等待io完成的百分比，这是值得观注的一项;
Ø %idle即空闲的百分比。
如果wio列的值很大，如在35%以上，说明系统的IO存在瓶颈，CPU花费了很大的时间去等待I/O的完成。Idle很小说明系统CPU很忙。像以上的示例，可以看到wio平均值为11，说明I/O没什么特别的问题，而idle值为零，说明cpu已经满负荷运行了。
当系统存在IO问题时，可以从以下几个方面解决：
Ø 联系相应的操作系统的技术支持对这方面进行优化，比如hp-ux在划定卷组时的条带化等方面。
Ø 查找Oracle中不合理的sql语句，对其进行优化;
Ø 对Oracle中访问量频繁的表除合理建索引外，再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。
1.2 关注内存
常用的工具便是vmstat，对于hp-unix来说，可以用glance。Aix来说可以用topas。当发现vmstat中pi列非零，memory中的free列的值很小，glance、topas中内存的利用率多于80%时，这时说明内存方面应该调节一下。方法大体有以下几项：
Ø 划给Oracle使用的内存不要超过系统内存的1/2，一般保在系统内存的40%为益。
Ø 为系统增加内存;
Ø 如果你的连接特别多，可以使用MTS的方式;
Ø 打全补丁，防止内存漏洞。
1.3 找到使用资源特别大的Oracle的session及其执行的语句
Hp-unix可以用glance或top。IBM AIX可以用topas。此外可以使用ps的命令。
通过这些程序可以找到点用系统资源特别大的这些进程的进程号，就可以通过以下的sql语句发现这个pid正在执行哪个sql，这个sql最好在pl/sql developer、toad等软件中执行：
SELECT a.username, a.machine, a.program, a.sid, a.serial#, a.status,
c.piece, c.sql_text
FROM v$session a, v$process b, v$sqltext c
WHERE b.spid = 'ORCL'
AND b.addr = a.paddr
AND a.sql_address = c.address(+)
ORDER BY c.piece;
可以把得到的这个sql分析一下，看一下它的执行计划是否走索引。对其优化避免全表扫描，以减少IO等待，从而加快语句的执行速度。
提示：在做优化sql时，经常碰到使用in的语句，这时一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。比如：
SELECT col1, col2, col3 FROM table1 a
WHERE a.col1 NOT IN (SELECT col1 FROM table2)
可以换成：
SELECT col1, col2, col3 FROM table1 a
WHERE NOT EXISTS
(SELECT 'x' FROM table2 b WHERE a.col1=b.col1)
1.4 查找前十条性能差的sql语句
SELECT * FROM (SELECT parsing_user_id, executions, sorts, command_type,
disk_reads, sql_text FROM v$sqlarea
ORDER BY disk_reads DESC)
WHERE ROWNUM<10;
第二章 检查会话状态
要快速发现Oracle Server的性能问题的原因，可以求助于v$session_wait视图，看系统的这些session在等什么，使用了多少的IO。以下是参考脚本：
-- 脚本说明：查看占I/O较大的正在运行的session：
SELECT se.sid, se.serial#, pr.spid, se.username, se.status, se.terminal,
se.program, se.mole, se.sql_address, st.event, st.p1text,
si.physical_reads, si.block_changes
FROM v$session se, v$session_wait st, v$sess_io si, v$process pr
WHERE st.sid=se.sid AND st.sid=si.sid
AND se.PADDR=pr.ADDR
AND se.sid>6
AND st.wait_time=0
AND st.event NOT LIKE '%SQL%'
ORDER BY physical_reads DESC;
对检索出的结果的几点说明：
1. 以上是按每个正在等待的session已经发生的物理读排的序，因为它与实际的I/O相关。
2. 可以看一下这些等待的进程都在忙什么，语句是否合理?
SELECT sql_address FROM v$session WHERE sid=;
SELECT * FROM v$sqltext WHERE address=;
执行以上两个语句便可以得到这个session的语句。
也以用alter system kill session 'sid, serial#';把这个session杀掉。
3. 应观注一下event列，这是调优的关键一列，下面对常出现的event做以简要的说明：
1) buffer busy waits，free buffer waits这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的free buffer wait的条目很小或没有时，说明系统的dbwr进程决对够用，不用调整;free buffer wait的条目很多，系统感觉起来一定很慢，这时说明dbwr已经不够用了，它产生的wio已经成为数据库性能的瓶颈，这时的解决办法如下：
Ø 增加写进程，同时要调整db_block_lru_latches参数：
示例：修改或添加如下两个参数
db_writer_processes=4
db_block_lru_latches=8
Ø 开异步IO。IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。
2) db file sequential read，指的是顺序读，即全表扫描，这也是应尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。
3) db file scattered read参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。
4) latch free与栓相关，需要专门调节。
5) 其他参数可以不特别观注
补充：解决系统变慢的常用技巧方法
1、在我的电脑窗口，右击要清理的盘符―“属性”―“清理磁盘”--勾选要删除的文件--确定--是。
2、右键浏览器e――属性――点2个删除1个清除(都要逐一确定)――确定 。
3、把C:WINDOWSPrefetch(预读文件)把里面的文件全部删除
4、用优化大师或超级兔子清理注册表和垃圾文件。
5、“开始”――运行中输入msconfig――确定――启动――除了输入法ctfmon以外的勾全去掉。
6、右键我的电脑”――属性――点高级――点启动和故障恢复中的设置――去掉所有的勾――写入调试信息选择“无”――确定――点高级下面错误报告――点禁用――2次确定。
7、“开始”..打开控制面板中的文件夹选项..点查看..点去末项自动搜索文件夹前面的勾..确定。
8、右键我的电脑――属性――硬件――设备管理器――双击IDE控制器――次要通道――高级设置――传送模式都选DMA――设备类型选无――确定――主要通道也同样设置――确定。
9、右键C盘进行磁盘清理和其它选项中的系统还原清理。
E. sql 数据库连接超时
原因分析:
查询超时一般来说首先要从sql语句和数据表的结构上找原因，优化sql语句和为数据库的查询字段建索引是最常用的办法。
另外，数据库的查询超时设置一般是sqlserver自己维护的（在你没有修改query wait配置前），只有当你的实际查询时间超过估计查询时间的25倍时，才会超时。
而造成超出估计值那么多的原因有两种可能:
一是估计时间不准确；
二是sql语句涉及到大量占用内存的查询（如排序和哈希操作），内存不够，需要排队等待资源造成的。
解决办法:
A.优化语句,创建/使用合适的索引;
B.解决第一个问题的方法,更新要查询表的索引分发统计，保证估计时间的正确性，UPDATE STATISTICS 表名;
C.增加内存
如果想手动设置查询超时，可以使用以下语句：
sp_configure 'show advanced options', 1 GO RECONFIGURE GO sp_configure 'query wait', 2147483647 GO RECONFIGURE GO
F. JAVA做的客户端连接SQL数据库超慢
如果你型滚悔配置数据语言的话那样链接就快多了卜正啊
呵呵要知道怎么配置数据语言的话你还要查点资料
不知备竖道 你用的什么数据库什么软件..不好说
G. 并发量大，sqlite数据库写入数据慢，有什么办法吗
建议不要使用sqlite这种数据库频繁执行读写操作，效率低。
如果不换数据库的话提供一条思路，使用缓存:用户访问时的插入语句放在一个字符串集合列表中，列表数量达到一定级别 例如1000条时，之后再用事务插入数据，然后删除。我曾经用sqlite连续插入过十万级别的数据，使用事务比遍历可以将插入时间压缩到十分之一左右
H. mysql数据库插入数据很慢
1.逐步排除法，输出几个重要步骤的执行时间，找出导致代码执行时间慢的真正原因，看看是读取excel慢还是插入数据库慢或者其他原因
I. sql数据库写入时慢做其他的很正常
数据量多大了？看看有没有一些不应该做索引的字段做了索引，如果写了触发器看看触发器的运行是否有问题。最好直接用SQL查询分析器运行下插入，看看问题所在。
J. 数据库写入数据很卡，查询也很慢，懂的高手请来，赏分解决可以追加分
看这种现象，估计是SQL语句写的不够好，SQL要用绑定变量的方式，影响查询性能主要就是执行SQL过多，而且SQL写的不好，无效索引过多，第一步必须优化SQL，之后就是清理历史数据，清理无用索引，大表数据可以用分区表，还有就是tomcat的性能也需要注意，如果太卡，重启一下tomcat试试，是否有效果