C#远程访问SQL特别慢

从数据库读取图片是个相当不理智的选择。你想读取快速就要在SQL Server上写存储过程，命名主键，然后直接用SqlClient访问你做好的视图，而不是利用SqlClient做解析、做连接查询等工作。因为他的计算效率依赖于网络，要分析也是从SQL读取表到本地，然后本地边读取边去查询远程表，这能不慢吗，写多了你慢慢会发现：

在SQL Server上做好查询视图，C#直接访问远远比C#分析快

用代码来做数据库 *** 作远远比自带的控件灵活快速

其实连接一样的你打开一次就足够了，程序Exit自然关闭，当你程序初始化的时候就openlink打开数据库连接，后面再去公用这个连接，程序关闭C#回收垃圾机制会销毁。不需要你真的去try打开他catch异常，flinnly关闭，不知道大家有没有发现连接数据库也需要时间的，关闭它也是浪费时间的。

触发器和同步用SQL Server代理去做，每日做好计划代理就OK

不要真的去把数据库发布到外部网络，在设备允许范围你会发现这是一个很蠢的事情，通过webservice或者WEB来 *** 作来自外网服务器的数据库。

用linkq解决很多问题，list<>远远比Arraylist要快，Arraylist依赖系统缓存，当你数据量超出系统缓存的时候，你会发现各种错误各种卡...

借助dataGridView，他其实是个好东西，你把数据存进去，再去交叉分析其他数据，会事半功倍，永远不要在C#里使用Select *，   连接查询 ，游标，检索ID，你会发现真的很呆

数据库慢一般有三种情况第一种情况 逐渐变慢 要建立一个长期的监控机制 比如 写个shell脚本每天的忙时(通常 ~ etc )定时收集os neork db的信息 每个星期出report对收集到的信息进行分析 这些数据的积累 可以决定后期的优化决策 并且可以是DBA说服manager采用自己决策的重要数据 DBA的价值 就在每个星期的report中体现

第二种情况 突然变慢 也是最容易解决的 先从业务的角度看是DB的使用跟以前有何不同 然后做进一步判断 硬件/网络故障通常也会引起DB性能的突然下降

第一步: 察看DB/OS/NEORK的系统log 排除硬件/网络问题

第二步 察看数据库的等待事件 根据等待事件来判断可能出问题的环节 如果 没有等待事件 可以排除数据库的问题 如果有等待时间 根据不同的等待事件 来找引起这些事件的根源

比如latch free等跟SQL parse有关系的等待事件 OS的表现是CPU 的占用率高

db file scattered read等跟SQL disk read有关系的等待时间 OS的表现是iostat可以看到磁盘读写量增加

第三步: 察看os的信息 CPU/IO/MEMORY等

a Cpu 的占用率

CPU占用率与数据库性能不成反比 CPU占用率高 不能说明数据库性能慢 通常情况 一个优化很好 而且业务量确实很大的数据库 CPU的占用率都会高 而且会平均分布在每个进程上 反过来 CPU的占用率都会高也不代表数据库性能就好 要结合数据库的等待事件来判断CPU占用率高是否合理

如果某个进程的cpu占用高 肯定是这个进程有问题 如果 不是oracle的进程 可以让application察看是否程序有死循环等漏洞 如果 是oracle的进程 可以根据pid查找oracle数据字典看看这个进程的发起程序 正在执行的sql语句 以及等待事件 然后 不同情况使用不同的方法来解决

b IO

排除硬件的IO问题 数据库突然变慢 一般来说 都是一个或几个SQL语句引起的

如果IO很频繁 可以通过优化disk reads高的TOP SQL来解决 当然这也是解决IO问题的最笨也是最有效的办法

OS以及存储的配置也是影响IO的一个重要的原因

比如 最常见的HP unix下异步IO的问题 如果DBA GROUP没有MLOCK的权限 ORACLE是不使用AIO的 偏偏OS与DB的两方的admin如果配合不够好地话 这个配置就很容易给漏掉了

c Memory

第二种情况与memory的关系比较小 只要SGA区配置合理没有变化 一般来说 只要不是Application Memory leak 不会引起突然变慢的现象

第三种情况 不定时变慢 是最难解决的 现场出现的问题原因也是五花八门千奇百怪 最重要的是 出现慢的现象时 以最快的速度抓取到最多的信息以供分析 先写好抓取数据的shell 脚本 并在现象发生时及时按下回车键

---