分布式应用是这样的：它分布在整个企业的一个或多个硬件平台，这些环境通常是与数据库服务器相分离的。而DBA的工作就是监视这些环境并配置和优化数据库服务器以满足多种需求。大数据的出现加剧了DBA的问题，因为现在多个分布式应用需要访问一个非常庞大的数据存储。那么在DB2的环境下，有哪些可用调优的方法呢?我们将在本文中进行详细介绍。
DBA必须首先解决常见的应用性能瓶颈。如果数据可用性或性能已经很差，那么面向高性能访问大数据就会出现问题。这里是一份常见的调优问题列表，DBA要确保数据库存在这些流程以减轻这些潜在的问题。
过度加锁
在DB2环境中有两个流程级别可以“存储”数据：SQL流程和数据库工具。SQL流程包括应用程序发布静态SQL语句和动态发布的SQL语句。SQL会发布针对数据的锁，并且这些锁通常会避免数据正在被读取的时候并发更新。此外，加锁会避免诸如Load之类的工具加载数据，这会导致取代或是覆盖正在被读取的数据。
工具会发布针对数据的声明。一条声明类似于数据库锁，是因为它可以通过实体来保留数据以供访问并避免某些并发的SQL访问。一般来说，加锁会强制声明去等待，而声明会强制SQL操作去等待。这就允许数据库管理系统可以管理多个诸如Load或是Image Copy之类的并发工具，而不用受到SQL语句的干扰。
最常见的加锁问题是SQL语句锁定太多的数据。一条SQL语句读取一条记录通常会在此SQL语句执行期间锁定多条记录为只读。这种行为在多个地方是受控的，包括语法，数据库定义，以及通过应用程序提交语句的用法。
DBA应该审查SQL语句加锁行为来确保锁定最小量的数据。了解锁定对象的大小和应用是如何访问数据的。长期运行的应用程序可能会长时间锁定数据，从而降低了数据可用性。考虑记录级别的锁定来最小化SQL的影响，尽管这可能会导致用于管理加锁的CPU时间有所上升。
应用程序提交逻辑同样应该加以审查，提交会释放锁定并允许数据访问。
此外，DBA应该审查应用程序和工具的调度。例如，验证诸如Image Copy这类工具在应用程序做数据库更新的时候没有在并发运行。
数据访问模式的糟糕设计
如果表中某个记录集访问频繁，那么它们便可成为一个“热点”。比如一个按订单号排序的订单表。最近的订单会在它们处理的时候更加活跃。由于多个应用程序和工具访问少量记录，那么数据访问的影响就会集中在数据库中的一个小范围内。当某些事务锁定或声明数据时，而其他应用程序或工具试图对它们进行访问，这通常就会导致性能问题。
这样的热点可以在数据库设计阶段加以预测。DBA可以在数据库中嵌入空白空间来分散数据，这样就降低了在一个物理点活动的集中程度。其他选项包括分配记录到整个数据库的方法。在我们以上的订单表例子中，DBA可能会实现以地理位置进行排序而非按订单号排序的表。这样，新订单就不会彼此相邻，而是分布于整个物理表。
大数据应用调优
大数据通常意味着一个需要高速数据分析软件的大型数据存储。很多时候这些大数据部署与企业数据仓库共存。这意味着DBA人员必须与数据仓库人员进行协作以保证良好的性能。下面提到的一些点需要我们充分考虑：
存储于非常大的DB2表中的大数据可能会有特殊的恢复需求。考虑一个要每天进行分析的事务数据的大型存储。业务管理者可能会认为此分析对日常生产至关重要，从而指定此数据为关键任务。如果发生故障，这些数据要怎样才能恢复呢?对于一个数据仓库最佳的做法就是指定数据在恢复上为低优先级的。
存储在DB2表中的大数据可能需要DBA去降低或是最小化数据上索引的数量。虽然通常来说可以添加多个索引到一个表来改善查询性能，而对于非常大的表其索引也会很大。磁盘存储限制可能会阻止DBA创建某些索引。此外，更多的索引会减缓数据插入性能，同样还会让任何数据库恢复过程运行更长的时间。
置于一个专门的软硬件一体化设备中的大数据必须经常由数据仓库表同时进行访问。这通常是利用SQL连接语句加以实现的。DBA必须协调大数据设备的加载和数据仓库的ETL流程以确保所有数据在查询阶段是可用的。
数据仓库访问优化
最后一点也是最重要的。数据仓库的ETL流程有其自身独特的性能问题。数据提取流程通常会作为多个并行数据查询流程加以执行。数据仓库团队可能会使用高速网络来加速这一流程。由于可操作数据可能不是以易于分析的形式呈现的，因此数据转换需要编程技能。常见问题有空值，缺失或未知数据，甚至是诸如日期值为 “99/99/9999”的无效数据。
最后，加载流程通常包括多个针对仓库表并发加载的工具。加载通常是长期运行和资源密集型的。
由于分布式应用试图访问大数据，它们也不可避免的会访问数据仓库数据。再次，DBA必须将此过程与数据仓库ETL过程加以协调。
常见的方法是架设有两个分区的表，活动和非活动分区。目标表物理上被分为数据集和分区。一个分区被指定为活动分区，而一个控制表或参数被设置用来指示哪个分区是活动的。分布式查询现在可能访问活动的数据，允许加载流程把数据加载到非活动分区。一旦加载完毕，活动和非活动标记就会切换。
分布式处理和大数据
优化分布式访问性能的一个最佳实践是使用资源约束分析。DBA会在收集性能数据的时候监视诸如磁盘子系统和CPU之类的资源。甚至查询和工作运行时间也可以被当做是资源。当DBA发现某项资源受限时，他们会平衡其他资源以进行弥补。
例如，考虑一个被多个分布式应用经常查询的大数据存储。DBA可能会确定运行时间(资源#1)太长。一项资源均衡操作可能会添加更多的索引到表中。这样便在加速了查询时间的同时使用了磁盘存储空间(资源#2)。
其他均衡操作包括删除索引，为DB2分配额外内存，增加DB2的排序工作区，查询调优，等等。这些以及其他方法都是记录在DB2性能手册中的。
总结
大数据可能意味着大的性能问题，并且通过分布式应用程序进行访问会将这些问题进一步复杂化。DBA可以通过考虑以下方面来主动了解这些问题：
数据库设计选项(活动/非活动分区，索引选择，分散数据到整个物理数据集);
利用Explain优化分布式查询;
协调大数据访问和数据仓库访问;
执行资源约束分析。
分布式应用程序对于DBA来说可能会是个挑战。通过解决当前以及潜在的数据可用性问题作为开始，尤其是那些企业数据仓库中的问题。一旦这些担忧得以缓解，那么DBA就可以开始管理对大数据的分布式数据访问。