一、语句中有中文的全变成乱码
Oracle原本是32位的，后面升级到64位后，Web连接到Oracle的语句中，有中文的执行到数据库里面全变成问号的乱码。
解决方案：我的电脑-右键-属性-高级-环境变量-系统变量-新建变量 变量名：NLS_LANG 变量值：AMERICAN_AMERICA.UTF8；
本文链接：http://www.cnblogs.com/ly360/p/3173285.html，转载请注明。
AWR 报告的“Load profile”节，如下图所示，包含很多极为有用，却被经常忽视的信息。通常更倾向使用“instance efficiency percentages”节，虽然可读性好，但很容易产生误解。
Per Second
Per Transaction
Per Exec
Per Call
DB Time(s):
0.1
0.2
0.01
0.08
DB CPU(s):
0.0
0.1
0.01
0.05
Redo size:
2,650.2
9,391.1
Logical reads:
863.7
3,060.4
Block changes:
31.6
112.1
Physical reads:
220.2
780.2
Physical writes:
0.7
2.3
User calls:
0.9
3.1
Parses:
2.4
8.4
Hard parses:
0.2
0.8
W/A MB processed:
356,098.6
1,261,849.5
Logons:
0.0
0.2
Executes:
5.3
18.9
Rollbacks:
0.0
0.0
Transactions:
0.3
Redo size
你在数据库所做的一切都被redo（重做）保护。重做是所谓“change vectors（变化向量）”的集合，告诉 Oracle 如何在数据上重复操作，如果需要的话。尽管 SELECT 也可以产生一些 redo，但是 redo 的主要来源（在大约降序排序）：INSERT，UPDATE 和 DELETE。对 INSERT 和 UPDATE，redo 大小接近创建或修改数据的数量。对与 DELETE，你只需要知道已删除行的rowid，以便重复操作，因此，如果数据行是“fat”，那么redo大小可能远小于已删除数据的大小。
高redo数值意味着，大量新的数据被保存到数据库中，或现有的数据发生很多的变化，即DML操作很频繁。
多高算高？数据库不一样，所以不存在通用的标准。不过，我发现每秒 redo 乘以 86,400 秒（24*60*60=86,400，一天的秒数）会很有用，并且把它与数据库的大小相比——如果数字是在同一量级（magnitude），那么这就让我很奇怪了。数据库的大小每隔几天增加一倍？或者几乎每天修改每一行吗？也许，有些正在发生的我不知道的事情？
如果发现 redo 代过高你会怎么做。留意任何可疑的DML活动。此外，务必看下“segments statistics”小结（physical writes 段、DB block changes 段等），看是否有任何线索。
Logical reads, block changes, physical reads/writes
简单来说，Logical reads 是数据库读取数据块的数量，包括 physical（例如，磁盘）reads，block changes 是自我描述。这些统计告诉我们报告时数据库活动的性质（多数在写，多数在读，读写都有一点）和规模。它也给出一个想法，缓存的数据如何在数据库更好地工作（但你也在“instance efficiencies”小节从buffer cache hit ratio直接看到）。
如果你发现该数值比预期（基于平时的数值，当前应用程序负载等）的高，那么你可以下钻到“SQL by logical reads” 和“SQL by physical reads”，看下是什么SQL语句造成的。
User calls
当一个数据库客户端要求服务器做某些事时，像logon、parse、execute、fetch 等，就叫 user call。这是相当有用的信息，因为它为其他统计设置了规模（如 commits、hard parses 等）。
特别是，当数据库正在执行很多次时，每个user call，这可能是一个迹象，过多的上下文切换（例如，由于不好的执行计划，SQL语句中的PL / SQL函数在过于频繁地被调用，因为一个糟糕的计划）。在这种情况下，看下“SQL ordered by executions”将是合乎逻辑的下一步。
Parses and hard parses
Parse是分析查询的文本（可选），优化执行计划。如果涉及优化执行计划，那么它是一个hard parse，否则soft parse。
正如我们都知道，Parse是昂贵的（性能明智）。过多Parse会导致非常讨厌的性能问题（一个时刻，你的数据库似乎很好，下一刻，就变成完全停顿）。过度Parse的另一个坏事是，它使故障排除性能较差的SQL 更 困难。
多糟的hard parse是可以接受的？这取决于很多东西，像CPU数量，执行次数，执行计划对SQL参数有多敏感等等，但是，一个经验法则，低于每秒1个hard parse可能是好的，每秒100个以上就有问题了（如果数据库中有很多CPU，比如100个以上，这些数字会相应地扩大）。它还有助于看数量的硬盘解析％执行（the number
一、定义
2个字节一个汉字，比如“的”； 全角标点2个字节，半角标点一个字节， 一个字母一个字节
字符指一个字母或一个字或一个标点或一个符号，不一定几个字节，看情况定 字呢，太泛了一点吧？
二、单位换算飞
一个汉字=两个位（2Byte)
一个英文字母=一个位(1Byte)
8bit(位)=1Byte(字节)
1024Byte(字节)=1KB
1024KB=1MB
1024MB=1GB
1024GB=1TB
三、各种编码中字符与字节的转换
字节是计算机得度量单位，八个二进制数字组成一个字节,英文名为BYTE
字符是计算机可以处理得符号得统称,比如1234..9及!@#$及abcd...z这种ASCII字符,以及"我是中国人"这种gb2312字符或者UNICODE字符
字符的大小可以用字节来衡量,比如ASCII字符的长度就是一个字节；gb2312字符得长度是两个字节；UNICODE字符得长度是3个字节。
ASCII 一个英文字母,数字-----占7/8字节,就是7个2进制位，第八个有其他用，比如奇偶校验，因此可以算占一个字节。（8个Bit位）
一个中文字-------占二个字节
整数要根据类型，一般是极其的字长。比如16位机整数就是16位Bit，两个字节。32位机就是4字节。还有int64 类型的整数。 至于实数在C中，有32位（float）和64位(double)之分。其他语言中有类型80位的，叫扩展精度实数.主要是在cpu内部的扩展精度实数寄存器，是80位的。保证在double实数运算是不损失精度。
本文链接：http://www.cnblogs.com/wllzbky/p/3176658.html，转载请注明。