数据库检测工具有哪些，常用的数据分析工具有哪些

1，常用的数据分析工具有哪些

开源大数据生态圈：HadoopHDFS、HadoopMapReduce,HBase、Hive渐次诞生

常用的数据分析工具有哪些

2，sql server 数据分析有哪些工具

SAP BO系列，如WEBI、crystalreport、dashboard、lumira、designer studiotableausmartBI、Echart、power BI等等多了去了

power BIexcel

sql server 数据分析有哪些工具

3，现在的SQLSERVER数据库监控软件有哪些

常用的有以下: 表由行和列构成的集合，用来存储数据数据类型定义列或变量的数据类型，sql server提供了系统数据类型，并允许用户自定义数据类型视图由表或其他视图导出的虚拟表索引为数据快速检索提供支持且可以保证数据唯一性的辅助数据结构约束用于为表中的列定义完整性的规则默认值为列提供的缺省值存储过程存放于服务器的预先编译好的一组t-sql语句触发器特殊的存储过程，当用户表中数据改变时，该存储过程被自动执行

现在的SQLSERVER数据库监控软件有哪些

4，监控数据库有什么工具

　　单一的工具适用性较差，可以考虑统一的运维监控工具。比如蚁巡运维平台来方便、统一的监控机房里的设备的运行状况。

在ｌｒ的帮助中，有默认的监控计数器，一般情况下，如果没有特殊的目的，使用这些计数器就可以了。如果你想知道一些特定的计数器的状态。就加进去。而对这些计数器的理解，不是ｌｒ的内容了。应该看数据库厂商的一些说明文档。

要看你使用的是什么数据库，如果是SQL SERVER 数据库本身有一个工具叫做 SQL SERVER Profiler,在工具里面。

oracle的话有toad

5，oracle哪个工具自动检测系统瓶颈并给出建议

ADDM(Automatic DatabaseDiagnostic Monitor)是植入Oracle数据库的一个自诊断引擎.ADDM 通过检查和分析AWR获取的数据来判断Oracle数据库中可能的问题. 在Oracle9i及之前，DBA们已经拥有了很多很好用的性能分析工具，比如，tkprof、sql_trace、statspack、setevent 10046&10053等等。这些工具能够帮助DBA很快的定位性能问题。但这些工具都只给出一些统计数据，然后再由DBA们根据自己的经验进行优化。 Oracle10g中推出了新的优化诊断工具：数据库自动诊断监视工具（Automatic Database Diagnostic Monitor :ADDM）和SQL优化建议工具（SQL Tuning Advisor: STA）。这两个工具的结合使用，能使DBA节省大量优化时间，也大大减少了系统宕机的危险。简单点说，ADDM就是收集相关的统计数据到自动工作量知识库(Automatic Workload Repository :AWR)中，而STA则根据这些数据，给出优化建议。例如，一个系统资源紧张，出现了明显的性能问题，由以往的办法，做个一个statspack快照，等30分钟，再做一次。查看报告，发现 dbfile scattered read事件在top 5 events里面。根据经验，这个事件一般可能是因为缺少索引、统计分析信息不够新、热表都放在一个数据文件上导致IO争用等原因引起的。根据这些经验，我们需要逐个来定位排除，比如查看语句的查询计划、查看user_tables的last_analysed子段，检查热块等等步骤来最后定位出原因，并给出优化建议。但是，有了STA以后，它就可以根据ADDM采集到的数据直接给出优化建议，甚至给出优化后的语句。ADDM能发现定位的问题包括：?操作系统内存页入页出问题?由于Oracle负载和非Oracle负载导致的CPU瓶颈问题?导致不同资源负载的TopSQL语句和对象——CPU消耗、IO带宽占用、潜在IO问题、RAC内部通讯繁忙?按照PLSQL和JAVA执行时间排的Top SQL语句.?过多地连接 (login/logoff).?过多硬解析问题——由于sharedpool过小、书写问题、绑定大小不适应、解析失败原因引起的。?过多软解析问题?索引查询过多导致资源争用.?由于用户锁导致的过多的等待时间(通过包dbms_lock加的锁)?由于DML锁导致的过多等待时间(例如锁住表了)?由于管道输出导致的过多等待时间(如通过包dbms_pipe.put进行管道输出)?由于并发更新同一个记录导致的过多等待时间(行级锁等待)?由于ITL不够导致的过多等待时间（大量的事务操作同一个数据块）?系统中过多的commit和rollback(logfilesync事件).?由于磁盘带宽太小和其他潜在问题（如由于logfile太小导致过多的checkpoint，MTTR设置问题，过多的undo操作等等）导致的IO性能问题I?对于DBWR进程写数据块，磁盘IO吞吐量不足?由于归档进程无法跟上redo日至产生的速度，导致系统变慢?redo数据文件太小导致的问题?由于扩展磁盘分配导致的争用?由于移动一个对象的高水位导致的争用问题?内存太小问题——SGATarget, PGA, Buffer Cache, Shared Pool?在一个实例或者一个机群环境中存在频繁读写争用的热块?在一个实例或者一个机群环境中存在频繁读写争用的热对象?RAC环境中内部通讯问题?LMS进程无法跟上导致锁请求阻塞?在RAC环境中由于阻塞和争用导致的实例倾斜?RMAN导致的IO和CPU问题?Streams和AQ问题?资源管理等待事件ADDM提供了一个整体的优化方案.基于一段时间内的AWRsnapshots(默认一小时一次)可以执行ADDM 分析,它可以帮我们诊断在这段期间内数据库可能存在的瓶颈.ADDM分析的目标是减小吞吐量的度量值, 在这里我们将它称为"DB TIME".DB TIME是一个累积值(数据库服务器处理用户请求所花费的时间).它包括了等待时间和CPU处理的时间(针对所有活跃的用户进程而言),可以通过查询下面两个视图来获得它的值: V$SESS_TIME_MODEL,V$SYS_TIME_MODEL. AWR收集的数据时放到内存中（sharepool），通过一个新的后台进程MMON定期写到磁盘中。所以10g的sharepool要求比以前版本更大，一般推荐比以前大15-20%。注意: ADDM不会将处理用户响应时间作为调优的目标,你应该使用"TRACE"技术来监控它.通过减小"DBTIME", 使用同样多的系统资源,数据库服务器可以处理更多的用户请求,也就是提高了吞吐量. 通过ADDM报告的问题是按照DBtime排序的.