Cassandra nodetool repair中的PR选项

Cassandra nodetool repair中的pr选项的官方解释是

Use -pr to repair only the first range returned by the partitioner.

那么什么时候用-pr选项,什么时候不用-pr呢?要解答这个问题首先要理解pr的意思

cassandra的数据可以有多份复制,比如说A,B,C,D四个节点,keyspace的replication factor为2

那么每份数据有两个copy,一个为primary,一个为replica

A节点上有range (D,A)的primary数据,同时也有range(C,D)的replica数据。如果在A节点上跑

nodetool repair -pr 那么会在A节点和B节点上同步range (D,A)的数据

如果是跑 nodetool repair 不加pr选项,那么会在
1. A节点和B节点上同步range (D,A)的数据
2. A节点和D节点上同步range (C,D)的数据

所以,如果你是为了处理delete的问题进行的日常的repair,可以使用-pr选项,在每个节点上跑一次。如果不加pr选项在每个节点上跑一次的话,会多做了重复的工作。再比如说增大replication factor,也可以使用-pr选项,在每个节点上跑。

如果是某个节点做recover操作的话,应该在该节点上不加pr选项,这样不单是同步了master的数据段,同样也同步了replica的数据段。如果是某个节点down掉,nodetool rebuild应该更快

另外,如果是多个data center, NetworkTopologyStrategy,可以加-local选项加快repair的速度
Use -local to only repair against nodes in the same data center.
最好使用CF级别的repair,将一个keyspace下的CF一个个的repair。

11203的parse count(total)中不包含softer soft parse

Jonathan Lewis在07年的一篇文章Parse Calls中详细介绍了parse相关的一些statistics.

在10g以及11202的oracle版本中parse count(total)是包含softer soft parse的(文章中提到),但是在11203中实验证明parse count(total)中不再包含softer soft parse。

我们来看实验结果:

首先是10g版本(11202的实验结果和10g是一样的)

我们执行一条很简单的SQL:

select count(*) from temp;

然后通过另外一个session查看v$sesstat

select a.name,b.value from v$statname a,v$sesstat b where a.STATISTIC#=b.STATISTIC# and b.sid=&&sid. and
(a.name like ‘parse count%’ or a.name like ‘session cursor cache hits’);

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 16
parse count (hard) 0
parse count (failures) 0

— execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 17 +1 — soft parse
parse count (hard) 0
parse count (failures) 0

— execute the count(*) SQL
NAME VALUE
—————————————————————- ———-
session cursor cache hits 3 +1 — softer soft parse
parse count (total) 18 +1
parse count (hard) 0
parse count (failures) 0

而在11203的版本中同样的测试,结果不一样

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 16
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

— execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 17 +1 soft parse
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

— execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 3 +1 softer soft parse
parse count (total) 17 (parse count total没有增加)
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

Posted in: Uncategorized |

11203的parse count(total)中不包含softer soft parse

Jonathan Lewis在07年的一篇文章Parse Calls中详细介绍了parse相关的一些statistics.

在10g以及11202的oracle版本中parse count(total)是包含softer soft parse的(文章中提到),但是在11203中实验证明parse count(total)中不再包含softer soft parse。

我们来看实验结果:

首先是10g版本(11202的实验结果和10g是一样的)

我们执行一条很简单的SQL:

select count(*) from temp;

然后通过另外一个session查看v$sesstat

select a.name,b.value from v$statname a,v$sesstat b where a.STATISTIC#=b.STATISTIC# and b.sid=&&sid. and
(a.name like ‘parse count%’ or a.name like ‘session cursor cache hits’);

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 16
parse count (hard) 0
parse count (failures) 0

— execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 17 +1 — soft parse
parse count (hard) 0
parse count (failures) 0

— execute the count(*) SQL
NAME VALUE
—————————————————————- ———-
session cursor cache hits 3 +1 — softer soft parse
parse count (total) 18 +1
parse count (hard) 0
parse count (failures) 0

而在11203的版本中同样的测试,结果不一样

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 16
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

— execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 2
parse count (total) 17 +1 soft parse
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

— execute the count(*) SQL

NAME VALUE
—————————————————————- ———-
session cursor cache hits 3 +1 softer soft parse
parse count (total) 17 (parse count total没有增加)
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0

也有可能是一些patch导致的问题,大家有兴趣也可以在自己的11203版本上试验一下。

如何查询运行在某个表上的所有SQL

这里说的所有SQL指的是存在于v$sql中还没有被age out出去的SQL. 一般频繁运行的SQL都是存在于v$sql中没有被age out出去的。

第一种方法最简单,也最不准确,就是直接查询sql_text

select * from v$sql where lower(sql_text) like ‘%TABLE_NAME%’

最不准确是因为他有几个问题:
1. table_name可能会被折行,这样like就无法被匹配
2. 可能存在表名一样,但是owner不一样的情况
3. 如果用户查询的是view或者synonym,SQL语句中没有真实的表名,这种方法也无法显示

使用这种方法主要是在当你要查询某个已知SQL的统计信息的时候。

第二种方法是通过查询v$sql_plan

select * from v$sql where hash_value in (select hash_value from v$sql_plan where object_owner=’xxx’ and object_name=’TABLE_NAME’);

SQL被分析后,执行计划会被存储在v$sql_plan中,object_name就是执行计划里面的name那一列。这种方法可以避免上面所说的三个问题。

但是这个方法也有个问题,就是当SQL执行计划中没有查询表的时候,SQL不会被显示,例如下面SQL的执行计划中没有表名,只有索引名

SYS@XFAN: SQL> explain plan for select * from test where x=1;

Explained.

SYS@XFAN: SQL> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
————————————————————————————————————————————
Plan hash value: 1416057887

————————————-
| Id | Operation | Name |
————————————-
| 0 | SELECT STATEMENT | |
|* 1 | INDEX RANGE SCAN| TEST_IDX |
————————————-

这时候查询表名是得不到该SQL的,必须查询索引名字。所以你可以稍微修改一下,将表名和索引名都加到object_name中:

select * from v$sql where hash_value in (select hash_value from v$sql_plan where
object_owner=’xxx’ and object_name in (‘TABLE_NAME’,’INDEX1_NAME’,’INDEX2_NAME’,…));

另外这种方法也可以用于查询哪些SQL使用了改索引

第三种方法是查询 v$object_dependency表

select * from v$sql where hash_value in (select FROM_HASH from v$object_dependency where TO_OWNER=’table owner’ and TO_NAME=’table name’);

这种方法应该是比较准确的,即使SQL中使用了view或者synonym,该方法还是可以找到SQL。 但是它不支持第二种方法的索引查询,dependency关系只是和表有关。