㈠ 衡量数据库性能的重要指标
具体来说，本文包括以下内容:
事务
查询性能
用户和查询冲突
容量
配置
Nosql 数据库
- 图1-基于基线评估当前事务响应时间
事务
事务可以观察真实用户的行为：能够在应用交互时捕获实时性能。众所周知，测量事务的性能包括获取整个事务的响应时间和组成事务的各个部分的响应时间。通常我们可以用这些响应时间与满足事务需求的基线对比，来确定当前事务是否处于正常状态。
如果你只想衡量应用的某个方面，那么可以评估事务的行为。所以，尽管容器指标能够提供更丰富的信息，并且帮助你决定何时对当前环境进行自动测量，但你的事务就足以确定应用性能。无需向应用程序服务器获取 CPU 的使用情况，你更应该关心用户是否完成了事务，以及该事务是否得到了优化。
补充一个小知识点，事务是由入口点决定的，通过该入口点可以启动事务与应用进行交互。
一旦定义了事务，会在整个应用生态系统中对其性能进行测量，并将每个事务与基线进行比对。例如，我们可能会决定当事务的响应时间与基线相比，一旦慢于平均响应时间的两个标准差是否就应该判定为异常，如图1所示。
用于评估事务的基线与正在进行的事务活动在时间上是一致的，但事务会由每个事务执行来完善。例如，当你选定一个基线，在当前事务结束之后，将事务与平均响应时间按每天的小时数和每周的天数进行对比，所有在那段时间内执行的事务都将会被纳入下周的基线中。通过这种机制，应用程序可以随时间而变化，而无需每次都重建原始基线；你可以将其看作是一个随时间移动的窗口。
总之，事务最能反映用户体验的测量方法，所以也是衡量性能状况最重要的指标。
查询性能
最容易检测到查询性能是否正常的指标就是查询本身。由查询引起的问题可能会导致时间太长而无法识别所需数据或返回数据。所以不妨在查询中排查以下问题。
1. 选择过多冗余数据
编写查询语句来返回适当的数据是远远不够的，很可能你的查询语句会返回太多列，从而导致选择行和检索数据变得异常缓慢。所以，最好是列出所需的列，而不是直接用 SELECT*。当需要在特定字段中查询时，该计划可能会确定一个覆盖索引从而加快结果返回。覆盖索引通常会包含查询中使用的所有字段。这意味着数据库可以仅从索引中产生结果，而不需要通过底层表来构建。
另外，列出结果中所需的列不仅可以减少传输的数据，还能进一步提高性能。
2. 表之间的低效联接
联接会导致数据库将多组数据带到内存中进行比较，这会产生多个数据库读取和大量 CPU。根据表的索引，联接还可能需要扫描两个表的所有行。如果写不好两个大型表之间的联接，就需要对每个表进行完整扫描，这样的计算量将会非常大。其他会拖慢联接的因素包括联接列之间存在不同的数据类型、需要转换或加入包含 LIKE 的条件，这样就会阻止使用索引。另外，还需注意避免使用全外联接；在恰当的时候使用内部联接只返回所需数据。
3. 索引过多或过少
如果查询优化没有可用的索引时，数据库会重新扫描表来产生查询结果，这个过程会生成大量的磁盘输入/输出（I/O）。适当的索引可以减少排序结果的需要。虽然非唯一值的索引在生成结果时，不能像唯一索引那样方便。如果键越大，索引也会变大，并通过它们创建更多的磁盘 I/O。大多数索引是为了提高数据检索的性能，但也需要明白索引本身也会影响数据的插入和更新，因为所有相关联的指标都必须更新。
4. 太多的SQL导致争用解析资源
任何 SQL 查询在执行之前都必须被解析，在生成执行计划之前需要对语法和权限进行检查。由于解析非常耗时，数据库会保存已解析的 SQL 来重复利用，从而减少解析的耗时。因为 WHERE 语句不同，所以使用文本值的查询语句不能被共享。这将导致每个查询都会被解析并添加到共享池中，由于池的空间有限，一些已保存的查询会被舍弃。当这些查询再次出现时，则需要重新解析。
用户和查询冲突
数据库支持多用户，但多用户活动也可能造成冲突。
1. 由慢查询导致的页/行锁定
为了确保查询产生精确的结果，数据库必须锁定表以防止在运行读取查询时再发生其他的插入和更新行为。如果报告或查询相当缓慢，需要修改值的用户可能需要等待至更新完成。锁提示能帮助数据库使用最小破坏性的锁。从事务数据库中分离报表也是一种可靠的解决方法。
2. 事务锁和死锁
当两个事务被阻塞时会出现死锁，因为每一个都需要使用被另一个占用的资源。当出现一个普通锁时，事务会被阻塞直到资源被释放。但却没有解决死锁的方案。数据库会监控死锁并选择终止其中一个事务，释放资源并允许该事务继续进行，而另一个事务则回滚。
3. 批处理操作造成资源争夺
批处理过程通常会执行批量操作，如大量的数据加载或生成复杂的分析报告。这些操作是资源密集型的，但可能影响在线用户的访问应用的性能。针对此问题最好的解决办法是确保批处理在系统使用率较低时运行，比如晚上，或用单独的数据库进行事务处理和分析报告。
容量
并不是所有的数据库性能问题都是数据库问题。有些问题也是硬件不合适造成的。
1. CPU 不足或 CPU 速度太慢
更多 CPU 可以分担服务器负载，进一步提高性能。数据库的性能不仅是数据库的原因，还受到服务器上运行其他进程的影响。因此，对数据库负载及使用进行审查也是必不可少的。由于 CPU 的利用率时时在变，在低使用率、平均使用率和峰值使用率的时间段分别检查该指标可以更好地评估增加额外的 CPU 资源是否有益。
2. IOPS 不足的慢磁盘
磁盘性能通常以每秒输入/输出操作（IOPS）来计。结合 I/O 大小，该指标可以衡量每秒的磁盘吞吐量是多少兆。同时，吞吐量也受磁盘的延迟影响，比如需要多久才能完成请求，这些指标主要是针对磁盘存储技术而言。传统的硬盘驱动器（HDD）有一个旋转磁盘，通常比固态硬盘（SSD）或闪存更慢。直到近期，SSD 虽然仍比 HDD 贵，但成本已经降了下来，所以在市场上也更具竞争力。
3. 全部或错误配置的磁盘
众所周知，数据库会被大量磁盘访问，所以不正确配置的磁盘可能带来严重的性能缺陷。磁盘应该适当分区，将系统数据目录和用户数据日志分开。高度活跃的表应该区分以避免争用，通过在不同磁盘上存放数据库和索引增加并行放置，但不要将操作系统和数据库交换空间放置在同一磁盘上。
4. 内存不足
有限或不恰当的物理内存分配会影响数据库性能。通常我们认为可用的内存更多，性能就越好。监控分页和交换,在多个非繁忙磁盘中建立多页面空间，进一步确保分页空间分配足够满足数据库要求；每个数据库供应商也可以在这个问题上提供指导。
5. 网速慢
网络速度会影响到如何快速检索数据并返回给终端用户或调用过程。使用宽带连接到远程数据库。在某些情况下，选择 TCP/IP 协议而不是命名管道可显着提高数据库性能。
配置
每个数据库都需设置大量的配置项。通常情况下，默认值可能不足以满足数据库所需的性能。所以，检查所有的参数设置，包括以下问题。
1. 缓冲区缓存太小
通过将数据存储在内核内存，缓冲区缓存可以进一步提高性能同时减少磁盘 I/O。当缓存太小时，缓存中的数据会更频繁地刷新。如果它再次被请求，就必须从磁盘重读。除了磁盘读取缓慢之外，还给 I/O 设备增添了负担从而成为瓶颈。除了给缓冲区缓存分配足够的空间，调优 SQL 查询可以帮助其更有效地利用缓冲区缓存。
2. 没有查询缓存
查询缓存会存储数据库查询和结果集。当执行相同的查询时，数据会在缓存中被迅速检索，而不需要再次执行查询。数据会更新失效结果，所以查询缓存是唯一有效的静态数据。但在某些情况下，查询缓存却可能成为性能瓶颈。比如当锁定为更新时，巨大的缓存可能导致争用冲突。
3. 磁盘上临时表创建导致的 I/O 争用
在执行特定的查询操作时，数据库需要创建临时表，如执行一个 GROUP BY 子句。如果可能，在内存中创建临时表。但是，在某些情况下，在内存中创建临时表并不可行，比如当数据包含 BLOB 或 TEXT 对象时。在这些情况下，会在磁盘上创建临时表。大量的磁盘 I / O 都需要创建临时表、填充记录、从表中选择所需数据并在查询完成后舍弃。为了避免影响性能，临时数据库应该从主数据库中分离出来。重写查询还可以通过创建派生表来减少对临时表的需求。使用派生表直接从另一个 SELECT 语句的结果中选择，允许将数据加到内存中而不是当前磁盘上。
NoSQL 数据库
NoSQL 的优势在于它处理大数据的能力非常迅速。但是在实际使用中，也应该综合参考 NoSQL 的缺点，从而决定是否适合你的用例场景。这就是为什么NoSQL通常被理解为 “不仅仅是 SQL”，说明了 NoSQL 并不总是正确的解决方案，也没必要完全取代 SQL，以下分别列举出五大主要原因。
1. 挑剔事务
难以保持 NoSQL 条目的一致性。当访问结构化数据时，它并不能完全确保同一时间对不同表的更改都生效。如果某个过程发生崩溃，表可能会不一致。一致事务的典型代表是复式记账法。相应的信贷必须平衡每个借方，反之亦然。如果双方数据不一致则不能输入。NoSQL 则可能无法保证“收支平衡”。
2. 复杂数据库
NoSQL 的支持者往往以高效代码、简单性和 NoSQL 的速度为傲。当数据库任务很简单时，所有这些因素都是优势。但当数据库变得复杂，NoSQL 会开始分解。此时，SQL 则比 NoSQL 更好地处理复杂需求，因为 SQL 已经成熟，有符合行业标准的接口。而每个 NoSQL 设置都有一个唯一的接口。
3. 一致联接
当执行 SQL 的联接时，由于系统必须从不同的表中提取数据进行键对齐，所以有一个巨大的开销。而 NoSQL 似乎是一个空想，因为缺乏联接功能。所有的数据都在同一个表的一个地方。当检索数据时，它会同时提取所有的键值对。问题在于这会创建同一数据的多个副本。这些副本也必须更新，而这种情况下，NoSQL 没有功能来确保更新。
4. Schema设计的灵活性
由于 NoSQL 不需要 schema，所以在某些情况下也是独一无二的。在以前的数据库模型中，程序员必须考虑所有需要的列能够扩展，能够适应每行的数据条目。在 NoSQL 下，条目可以有多种字符串或者完全没有。这种灵活性允许程序员迅速增加数据。但是，也可能存在问题，比如当有多个团体在同一项目上工作时，或者新的开发团队接手一个项目时。开发人员能够自由地修改数据库，也可能会不断实现各种各样的密钥对。
5. 资源密集型
NoSQL 数据库通常比关系数据库更加资源密集。他们需要更多的 CPU 储备和 RAM 分配。出于这个原因，大多数共享主机公司都不提供 NoSQL。你必须注册一个 VPS 或运行自己的专用服务器。另一方面，SQL 主要是在服务器上运行。初期的工作都很顺利，但随着数据库需求的增加，硬件必须扩大。单个大型服务器比多个小型服务器昂贵得多，价格呈指数增长。所以在这种企业计算场景下，使用 NoSQL 更为划算，例如那些由谷歌和 Facebook 使用的服务器。
㈡ 衡量计算机存储能力的指标是什么
衡量计算机存储能力的指标是内存容量。
计算机的内存容量通常是指随机存储器的容量，是内存条的关键性参数。内存的容量一般都是2的整次方倍，比如64MB、128MB、256MB等，一般而言，内存容量越大越有利于系统的运行。
进入21世纪初期，台式机中主流采用的内存容量为2GB或4GB，512MB、256MB的内存岩竖已较少采用。 系统对内存的识别是以Byte为单位，每个字节由8位二进制迟枣游数组成，即8bit（比特，也称“位”）。按照计算机的二进制方式，1Byte=8bit；1KB=1024Byte；1MB=1024KB；1GB=1024MB；1TB=1024GB。
系统中内存的数量等于插在主板内存插槽上所有内存条容量的总和，内存容量的上限一般由主板芯片组和内存插槽决定。
关于内存的介绍：
内存是计算机的重要部件，也称内存储器和主存储器，它用于暂时存放CPU中的运算数据，以及与硬盘等外部存储器交换的数据。它是外存与CPU进行沟通的桥梁，计算机中所有程序的运行都在内存中进行，内存性能的强弱影码销响计算机整体发挥的水平。只要计算机开始运行，操作系统就会把需要运算的数据从内存调到CPU中进行运算，当运算完成，CPU将结果传送出来。
我们平时输入一段文字或玩一个游戏，其实是在内存中进行。好比在一个书房，存放书籍的书架和书柜相当于电脑的外存，我们工作的办公桌相当于内存。通常，我们把要永久保存、大量数据存储在外存上，把一些临时或少量的数据和程序放在内存上。当然，内存的好坏会直接影响电脑的运行速度。
㈢ 硬盘存储容量是衡量其性能的重要指标
硬盘的性能指标： 一、容量 作为计算机系统的数据存储器，容量是硬盘最主要的参数。 硬盘的容量以兆字节（MB）或千兆字节（GB）为单位，1GB=1024MB。但硬盘厂商在标称硬盘容量时通常取1G=1000MB，因此我们在BIOS中或在格式化硬盘时看到的容量会比厂家的标称值要小。 硬盘的容量指标还包括硬盘的单碟容量。所谓单碟容量是指硬盘单片盘片的容量，单碟容量越大，单位成本越低，平均访问时间也越短。 二、转速 转速(Rotationl Speed 或Spindle speed)，是硬盘内电机主轴的旋转速度，也就是硬盘盘片在一分钟内所能完成的最大转数。转速的快慢是标示硬盘档次的重要参数之一，它是决定。硬盘的性能指标，包括硬盘容量、硬盘速度、硬盘转速、接口、缓存、硬盘单碟容量等。 1、硬盘容量 作为计算机系统的数据存储器，容量是硬盘最主要的参数。对于用户而言，硬盘的容量就象内存一样，永远只会嫌少不会嫌多。 硬盘的容量以兆字节(MB)或千兆字节(GB)为单位，1GB=1024MB。但硬盘厂商在标称硬盘容量时通常取1G=1000MB，因此我们在BIOS中或在格式化硬盘时看到的容量会比厂家的标称值要小。 2、硬盘转速 转速(Rotationl Speed 或Spindle speed)，是硬盘内电机主轴的旋转速度，也就是硬盘盘片在一分钟内所能完成的最大转数。转速的快慢是标示硬盘档次的重要参数之一。
㈣ 数据库性能优化基准测试的度量指标有哪些
当前业界常见的服务器性能指标有:
TPC-C
TPC-E
TPC-H
SPECjbb2005
SPECjEnterprise2010
SPECint2006 及 SPECint_rate_2006
SPECfp2006 及 SPECfp_rate_2006
SAP SD 2-Tier
LINPACK
RPE2
一、TPC (Transaction Processing Performance Council) 即联机交易处理性能协会, 成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标: 为业界提供可信的数据库及交易处理基准测试结果,当前发 布主要基准测试为:
TPC-C : 数据库在线查询(OLTP)交易性能
TPC-E : 数据库在线查询(OLTP)交易性能
TPC-H : 商业智能 / 数据仓库 / 在线分析(OLAP)交易性能
1.TPC-C测试内容：数据库事务处理测试, 模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现. 正规 TPC-C 测试结果发布必须提供 tpmC值, 即每分钟完成多少笔 TPC-C 数据库交易 (TPC-C Transaction Per Minute), 同时要提供性价比$/tpmC。如果把 TPC-C 测试结果写成为 tpm, TPM, TPMC, TPCC 均不属正规。
2.TPC-E测试内容：数据库事务处理测试，模拟一个证券交易系统。与TPC-C一样，实际衡量服务器及数据库软件处理在线查询交易处理（OLTP）的性能表现。正规TPC-E测试结果必须提供tpsE值，即每秒钟完成多少笔TPC-E数据库交易（transaction per second），同时提供$/tpsE。测试结果写成其他形式均不属正规。
对比：TPC-E测试较TPC-C测试，在测试模型搭建上增加了应用服务器层，同时增加了数据库结构的复杂性,测试成本相对降低。截止目前，TPC-E的测试结果仅公布有50种左右，且测试环境均为PC服务器和windows操作系统，并无power服务器的测试结果。除此之外，TPC官方组织并未声明TPC-E取代TPC-C，所以，说TPC-E取代TPC-C并没有根据。
㈤ 如何检查oracle数据库性能
oracle的性能判断需要综合数据库的多个运行指标来判断：
1、进程数量和占用cpu：这个主要看有没有长时间占用cpu的进行。通常会判断大出sql，需要优化；这个可以用执行计划或者awr报告查看；
2、内存占用：主要用系统命令查看ora_占用和系统总内存的比例，swap的使用率；通常swap使用率低就没事；这个主要使用系统命令；
3、磁盘占用率：防止磁盘空间不足，需要的主要在系统和用户表空间、RMAN等操作上；这个主要使用系统命令；RMAN命令查看
㈥ 如何检查oracle数据库性能
这种问题要回答好要求知识比较全面。
1 从操作系统层次上看
看CPU 内存 swqp（交换分区）等使用率
2 从磁盘上看
主要看磁盘读写。可以用dd测磁盘读写的速度 也可以在业务高峰期检测磁盘的速率。
3 从数据库本身来看。
先要看数据库各个参数的值 。 如sga的大小，process的大小，redo日志的个数与大小等这些关系到性能的参数是否设置合理。
长期观察的方式就是看各个时期的AWR报告。里面有各种性能指标，以及按执行时间或资源排列的sql ，以及各种等待时间的排名。从这里面可以掌握数据库的长期的性能变化。
即时观察的方式就是利用各种sql 查询 数据库在当前时间的各个性能指标(AWR报告里面的各种指标也都是通过sql查询出来的)
还有对数据库整体的一个检查：
如 表的大小，表是否需要分区而没有分区，索引是否创建，索引是否失效，开发人员写的sql是否正确使用到了索引，频繁使用的sql是否有绑定变量，有频繁大批量增删改的表是否存在高水位。。。
额 总之，这个话题涉及的知识非常多，尽可能多的学习一些东西，祝你好运。