在实际上DB2数据库设计中物理设计应该尽可能的与其逻辑结构相近，但是为性能做出的物理设计改变不能被忽略，因为它们并不来自于逻辑设计。
DB2数据库性能理解的主要误区:
逻辑设计应该总是能和物理设计完全映射
实际：DB2数据库设计中物理设计应该尽可能的和逻辑结构相近，但是为DB2数据库性能做出的物理设计改变不能被忽略，因为它们并不来自于逻辑设计。
将所有东西放在一个缓冲池(BP0)中让DB2管理
实际：就像在DB2手册和其他地方说明的一样，你只能在你的内存非常受限的情况下(10000 4k pages或者更少)，你没有时间去管理它，你也没有考虑到性能的条件下，去这样做。***这样说：不要放置除了DB2 catalog和目录以外的东西进入BP0。
DSNDB07是100%顺序的
实际：DSNDB07从来就不是100%顺序的，因为有工作文件中的对页面进行的随机活动。随即活动可能高达45%，但是通常范围是3%到10%。
VARCHAR应该总是被放置在行末
实际：这就是总是引发问题的话。如果表总是被读，并且非常少的更新，那么可以，这将会减少CPU负载，但是在其它情况下这样做就是最坏的，甚至如果表是被压缩的。只有在频繁更新的情况下它应该被放置在末尾，但是并不通常这样。
程序应该以遵循逻辑过程的方式编码
实际：伪代码或者一个逻辑过程图并不需要考虑DB2数据库性能相关的编码方式。在OLTP交易代码中这非常具有戏剧性。
大多数过程不在SQL中进行
实际：事实上，问题的反面往往是正确的。SQL是一个非常丰富的语言，能够处理大多数过程。实际上***的困难是SQL经常被用来作为I/O处理器而不是一个集合处理器。
代码和引用表应该和DB2声明的referential integrity(RI)一起使用
实际：RI不应该作为一个编辑有效性的快捷方式而使用，这通常属于别的什么，但是应该在真父子关系中使用。
表至多有一到两个索引
实际：表应该按照性能需求拥有多个索引。
非分割索引(NPI)不应该被使用，尤其是不应该在大的表中使用
实际：这关系到数不清的问题，总体上这些都能被克服，但是NPI是对适当的访问和性能非常必要的。
大表应该被分割
实际：因为一个表中有太多数据就意味着有DB2数据库性能下降，这是一个遗留的担心。当一些表中有超过60亿行数据时，这个理解已经被消除了。
DB2缺省就是好的
实际：缺省的一般不是***的，他们因版本不同而改变。比如考虑绑定参数CURRENTDATA。
不要在SQL WHERE谓词里使用否定
实际：另外一个这种规则并没有被解释清楚。只有谓词是一个否定时，SQL访问路径可能使用一个不必要的表空间扫描。但是在其它的多数情况下，多余的过滤应该在DB2引擎里完成，这会较好。
我可以只依靠EXPLAIN来决定是否访问路径是好的
实际：EXPLAIN不显示执行的查询块的顺序，不会告诉你1或者2阶段的谓词，不会告诉你一个块会多长时间执行一次。基本的，EXPLAIN只是导出一些数据到一个表里，然后结合其他一些信息来进行更多的一些解释。有一些工具来帮助处理此过程(如Visual Explain)，但是如果所有的事实都没有被考虑的话，这样的方式只会带来坏处。
不要做EDM池太大以避免其分页
实际：EDM池通常通过分页来提升DB2数据库性能(这里分页是指扩展存储，而不是磁盘)而不是变得更小并且因为页面置换和其他因素持续重建内部结构。
扩展不会关系其他任何东西
实际：什么时候开始的?未来如果世界上充满了SAN或者ESS，那差不多。扩展的影响已经因为新的磁盘缓存控制器而变得很小了，但是仍然有一些额外的检查和处理需要来管理它们。
关系的划分不会在DB2中使用
实际：关系的划分已经在过去的许多系统中被使用了，可以有效的通过数据库设计者和程序开发者来实现。在目前的商业智能(BI)和市场系统中，它可以被数次用在每个单个程序中。
将所有的包绑定到两个计划中：一个批处理和一个在线的
实际：在介绍DB2包的时候，这是一个不好的陈述。有许多理由可以说这个理解是错误的。
未授权的读是不好的
实际：未授权的读并不是一个四字单词但是是一个非常好的性能增强，可以被用在比经常理解的更多的地方。
在没有超时和死锁的情况下不会有锁问题
实际：事实上没有一个问题发生并不意味着没有需要关注的的DB2数据库性能问题。经常锁定不被认为是一个问题，因为注意力主要放在反应的调节测量(统计死锁或者超时的数量)，而不是后发式的调节(监控锁等待时间)。
ESA数据压缩总是好的
实际：当压缩能被在很多地方起作用时，有一些情况它能带来问题。每种情况都要在压缩使用前决定是否使用它。这不是可选的，而是必须要在高层决定是否使用还是不使用。
【编辑推荐】
什么是磁盘阵列？？
从RAID1到RAID5的几种方案中，不论何时有磁盘损坏，都可以随时拔出损坏的磁盘再插入好的磁盘(需要硬件上的热插拔支持)，数据不会受损，失效盘的内容可以很快地重建，重建的工作也由RAID硬件或RAID软件来完成。 但RAID0不提供错误校验功能，所以有人说它不能算作是RAID，其实这也是RAID0为什么被称为0级RAID的原因--0本身就代表没有。 1.3 RAID 的应用当前的PC机，整个系统的速度瓶颈主要是硬盘。 虽然不断有Ultra DMA33、 DMA66、DMA100等快速的标准推出，但收效不大。 在PC中，磁盘速度慢一些并不是太严重的事情。 但在服务器中，这是不允许的，服务器必须能响应来自四面八方的服务请求，这些请求大多与磁盘上的数据有关，所以服务器的磁盘子系统必须要有很高的输入输出速率。 为了数据的安全，还要有一定的容错功能。 RAID 提供了这些功能，所以RAID被广泛地应用在服务器体系中。 1.4 RAID 提供的容错功能是自动实现的(由RAID硬件或是RAID软件来做)。 它对应用程序是透明的，即无需应用程序为容错做半点工作。 要得到最高的安全性和最快的恢复速度，可以使用RAID1(镜像)；要在容量、容错和性能上取折衷可以使用RAID 5。 在大多数数据库服务器中，操作系统和数据库管理系统所在的磁盘驱动器是RAID 1，数据库的数据文件则是存放于RAID5的磁盘驱动器上。 1.5 有时我们看某些名牌服务器的配置单，发现其CPU并不是很快，内存也算不上是很大，显卡更不是最好，但价格绝对不菲。 是不是服务器系统都是暴利产品呢？当然不是。 服务器的配置与一般的家用PC的着重点不在一处。 除去更高的稳定性外，冗余与容错是一大特点，如双电源、带电池备份的磁盘高速缓冲器、热插拔硬盘、热插拔PCI插槽等。 另一个特点就是巨大的磁盘吞吐量。 这主要归功于RAID。 举一个例子来说，一台使用了SCSI RAID的奔腾166与一台IDE硬盘的PIIICopermine 800都用做文件服务器，奔腾166会比PⅢ的事务处理能力高上几十倍甚至上百倍，因为PⅢ处理器的运算能力根本用不上，反倒是奔腾166的RAID起了作用。 1.6 RAID现在主要应用在服务器，但就像任何高端技术一样，RAID也在向PC机上转移。 也许所有的 PC 机都用上了SCSI磁盘驱动器的RAID的那一天，才是PC机真正的出头之日
4、空间数据库中,矢量数据的管理方式有哪些,各有什么优缺点?
1、文件-关系数据库混合管理方式不足：①属性数据和图形数据通过ID联系起来，使查询运算，模型操作运算速度慢；② 数据分布和共享困难；③属性数据和图形数据分开存储，数据的安全性、一致性、完整性、并发控制以及数据损坏后的恢复方面缺少基本的功能；④缺乏表示空间对象及其关系的能力。 因此，目前空间数据管理正在逐步走出文件管理模式。 2、全关系数据库管理方式对于变长结构的空间几何数据，一般采用两种方法处理。 ⑴ 按照关系数据库组织数据的基本准则，对变长的几何数据进行关系范式分解，分解成定长记录的数据表进行存储。 然而，根据关系模型的分解与连接原则，在处理一个空间对象时，如面对象时，需要进行大量的连接操作，非常费时，并影响效率。 ⑵ 将图形数据的变长部分处理成Binary二进制Block块字段。 3、对象-关系数据库管理方式由于直接采用通用的关系数据库管理系统的效率不高，而非结构化的空间数据又十分重要，所以许多数据库管理系统的软件商在关系数据库管理系统中进行扩展，使之能直接存储和管理非结构化的空间数据。 这种扩展的空间对象管理模块主要解决了空间数据的变长记录的管理，由数据库软件商进行扩展，效率要比前面所述的二进制块的管理高得多。 但是它仍然没有解决对象的嵌套问题，空间数据结构也不能内用户任意定义，使用上仍受到一定限制。 矢量图形数据与属性数据的管理问题已基本得到解决。 从概念上说，空间数据还应包括数字高程模型、影像数据及其他专题数据。 虽然利用关系数据库管理系统中的大对象字段可以分块存贮影像和DEM数据，但是对于多尺度DEM数据，影像数据的空间索引、无缝拼接与漫游、多数据源集成等技术还没有一个完整的解决方案。
jsp页面提交数据到servlet处理,之后返回到另外一个jsp页面,怎样避免刷新重复提交?
使用token，比如到a页面前，生成一个随机6位数或字符串，保存到session中，并传到a页面设为隐藏域，a页面提交后，到servlet中，把提交的隐藏域中的前面生成的随机数或字符串与session中的比较，如果相等，就是正常提交，然后删除session中储存的值，以后即使重复提交，session当然不会有值或者值不同，就可以进行相应处理。
发表评论