Index full scan vs index fast full scan

Robert 发表于 2008-07-02 01:03:37

Index full scan vs index fast full scan

index full scan和index fast full scan是指同样的东西吗？答案是no。两者虽然从字面上看起来差不多，但是实现的机制完全不同。我们一起来看看两者的区别在哪里?
 
首先来看一下IFS,FFS能用在哪里：
在一句sql中，如果我们想搜索的列都包含在索引里面的话，那么index full scan 和 index fast full scan都可以被采用代替full table scan。比如以下语句：
 
SQL>create table test as select * from dba_objects where 0=1;
SQL>create index ind_test_id on test(object_id);
SQL>  insert into test select * from dba_objects where object_id is not null and object_id>10000 order by object_id desc;
17837 rows created.
SQL> analyze table test compute statistics for table for all columns for all indexes;
Table analyzed.
 
 
SQL> set autotrace trace;
SQL> select object_id from test;
17837 rows selected.

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=68 Card=17837 Bytes=
          71348)
   1    0   TABLE ACCESS (FULL) OF 'TEST' (Cost=68 Card=17837 Bytes=71
          348)
 
 
这时候oracle会选择全表扫描，因为object_id列默认是可以为null的，来修改成not null;
SQL>alter table test modify(object_id not null);
 

SQL> select object_id from test;
17837 rows selected.

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=11 Card=17837 Bytes=
          71348)
   1    0   INDEX (FAST FULL SCAN) OF 'IND_TEST_ID' (NON-UNIQUE) (Cost
          =11 Card=17837 Bytes=71348)
 
 
当然我们也可以使用index full scan
 
SQL> select/*+ index(test ind_TEST_ID)*/ object_id from test;
17837 rows selected.

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=41 Card=17837 Bytes=
          71348)
   1    0   INDEX (FULL SCAN) OF 'IND_TEST_ID' (NON-UNIQUE) (Cost=101
          Card=17837 Bytes=71348)
 
 
 
我们看到了两者都可以在这种情况下使用，那么他们有什么区别呢？
 
有个地方可以看出两者的区别，来看一下两者的输出结果，为了让大家看清楚一点，我们只取10行。
 
INDEX FAST FULL SCAN
 
SQL> select object_id from test where rownum<11;
 OBJECT_ID
----------
     66266
     66267
     66268
     66269
     66270
     66271
     66272
     66273
     66274
     66275
10 rows selected.

 
INDEX FULL SCAN

SQL> select/*+ index(test ind_TEST_ID)*/ object_id from test  where rownum<11;
 OBJECT_ID
----------
     10616
     12177
     12178
     12179
     12301
     13495
     13536
     13539
     13923
     16503
10 rows selected.
 
 
可以看到两者的结果完全不一样，这是为什么呢？这是因为当进行index full scan的时候oracle定位到索引的root block，然后到branch block（如果有的话），在定位到第一个leaf block,然后根据leaf block的双向链表顺序读取。它所读取的块都是有顺序的，也是经过排序的。
 
而index fast full scan则不同，它是从段头开始，读取包含位图块，root block,所有的branch block,leaf block，读取的顺序完全有物理存储位置决定，并采取多块读，没次读取db_file_multiblock_read_count个块。
 
这就是为什么两者的结果区别如此之大的原因，我们再仔细跟踪一下这两条语句。
 
首先来看一下索引的结构
 
SQL> select object_id from dba_objects where object_name='IND_TEST_ID';
 OBJECT_ID
----------
     70591
索引的object_id为70591，使用tree dump可以看到索引树的结构
SQL> ALTER SESSION SET EVENTS 'immediate trace name TREEDUMP level 70591';
----- begin tree dump
branch: 0x6809b8d 109091725 (0: nrow: 100, level: 1)
   leaf: 0x6809b96 109091734 (-1: nrow: 294 rrow: 0)
   leaf: 0x6c07ec1 113278657 (0: nrow: 262 rrow: 0)
   leaf: 0x6c07ebd 113278653 (1: nrow: 518 rrow: 0)
   leaf: 0x6c07eb1 113278641 (2: nrow: 524 rrow: 0)
   leaf: 0x6c07ead 113278637 (3: nrow: 524 rrow: 0)
   leaf: 0x6c07ea9 113278633 (4: nrow: 524 rrow: 0)
   leaf: 0x6c07ea5 113278629 (5: nrow: 524 rrow: 0)
   leaf: 0x6c07ea1 113278625 (6: nrow: 524 rrow: 0)
   leaf: 0x6c07e9d 113278621 (7: nrow: 524 rrow: 0)
   leaf: 0x6c07e99 113278617 (8: nrow: 524 rrow: 0)
   leaf: 0x6c07e95 113278613 (9: nrow: 532 rrow: 0)
   leaf: 0x6c07e91 113278609 (10: nrow: 524 rrow: 0)
   leaf: 0x6c07e8d 113278605 (11: nrow: 524 rrow: 0)
   leaf: 0x6c07ec8 113278664 (12: nrow: 524 rrow: 0)
   leaf: 0x6c07ec4 113278660 (13: nrow: 524 rrow: 0)
   leaf: 0x6c07ec0 113278656 (14: nrow: 524 rrow: 0)
   leaf: 0x6c07ebc 113278652 (15: nrow: 524 rrow: 0)
   leaf: 0x6809bb2 109091762 (16: nrow: 524 rrow: 0)
   leaf: 0x6c07eb8 113278648 (17: nrow: 524 rrow: 0)
   leaf: 0x6c07eb4 113278644 (18: nrow: 524 rrow: 0)
   leaf: 0x6c07eb0 113278640 (19: nrow: 524 rrow: 0)
   leaf: 0x6c07eac 113278636 (20: nrow: 524 rrow: 0)
   leaf: 0x6809bae 109091758 (21: nrow: 524 rrow: 0)
   leaf: 0x6c07ea8 113278632 (22: nrow: 524 rrow: 0)
   leaf: 0x6c07ea4 113278628 (23: nrow: 524 rrow: 0)
   leaf: 0x6c07ea0 113278624 (24: nrow: 105 rrow: 105)
   leaf: 0x6c07e9c 113278620 (25: nrow: 129 rrow: 129)
   leaf: 0x6c07eb9 113278649 (26: nrow: 123 rrow: 123)
   leaf: 0x6809baa 109091754 (27: nrow: 246 rrow: 246)
   leaf: 0x6c07e98 113278616 (28: nrow: 246 rrow: 246)
   leaf: 0x6c07e94 113278612 (29: nrow: 246 rrow: 246)
   leaf: 0x6809ba6 109091750 (30: nrow: 246 rrow: 246)
   leaf: 0x6809bce 109091790 (31: nrow: 246 rrow: 246)
   leaf: 0x6809bca 109091786 (32: nrow: 246 rrow: 246)
   leaf: 0x6809c05 109091845 (33: nrow: 248 rrow: 248)
   leaf: 0x6809c01 109091841 (34: nrow: 246 rrow: 246)
   leaf: 0x6809bfd 109091837 (35: nrow: 246 rrow: 246)
   leaf: 0x6809bf9 109091833 (36: nrow: 246 rrow: 246)
   leaf: 0x6809bf5 109091829 (37: nrow: 246 rrow: 246)
   leaf: 0x6809bf1 109091825 (38: nrow: 246 rrow: 246)
   leaf: 0x6809bed 109091821 (39: nrow: 246 rrow: 246)
   leaf: 0x6809be9 109091817 (40: nrow: 246 rrow: 246)
   leaf: 0x6809be5 109091813 (41: nrow: 246 rrow: 246)
   leaf: 0x6809be1 109091809 (42: nrow: 246 rrow: 246)
   leaf: 0x6809bdd 109091805 (43: nrow: 246 rrow: 246)
   leaf: 0x6809bd9 109091801 (44: nrow: 246 rrow: 246)
   leaf: 0x6809bd5 109091797 (45: nrow: 246 rrow: 246)
   leaf: 0x6809bd1 109091793 (46: nrow: 248 rrow: 248)
   leaf: 0x6809bcd 109091789 (47: nrow: 246 rrow: 246)
   leaf: 0x6809bc9 109091785 (48: nrow: 246 rrow: 246)
   leaf: 0x6809c08 109091848 (49: nrow: 246 rrow: 246)
   leaf: 0x6809c04 109091844 (50: nrow: 246 rrow: 246)
   leaf: 0x6809c00 109091840 (51: nrow: 246 rrow: 246)
   leaf: 0x6809bfc 109091836 (52: nrow: 246 rrow: 246)
   leaf: 0x6809bf8 109091832 (53: nrow: 246 rrow: 246)
   leaf: 0x6809bf4 109091828 (54: nrow: 246 rrow: 246)
   leaf: 0x6809bf0 109091824 (55: nrow: 246 rrow: 246)
   leaf: 0x6809bec 109091820 (56: nrow: 246 rrow: 246)
   leaf: 0x6809be8 109091816 (57: nrow: 246 rrow: 246)
   leaf: 0x6809be4 109091812 (58: nrow: 246 rrow: 246)
   leaf: 0x6809be0 109091808 (59: nrow: 248 rrow: 248)
   leaf: 0x6809bdc 109091804 (60: nrow: 246 rrow: 246)
   leaf: 0x6809bd8 109091800 (61: nrow: 246 rrow: 246)
   leaf: 0x6809bd4 109091796 (62: nrow: 246 rrow: 246)
   leaf: 0x6809bd0 109091792 (63: nrow: 246 rrow: 246)
   leaf: 0x6809bcc 109091788 (64: nrow: 246 rrow: 246)
   leaf: 0x6809c07 109091847 (65: nrow: 246 rrow: 246)
   leaf: 0x6809c03 109091843 (66: nrow: 246 rrow: 246)
   leaf: 0x6809bff 109091839 (67: nrow: 246 rrow: 246)
   leaf: 0x6809bfb 109091835 (68: nrow: 246 rrow: 246)
   leaf: 0x6809bf7 109091831 (69: nrow: 246 rrow: 246)
   leaf: 0x6809bf3 109091827 (70: nrow: 246 rrow: 246)
   leaf: 0x6809bef 109091823 (71: nrow: 246 rrow: 246)
   leaf: 0x6809beb 109091819 (72: nrow: 248 rrow: 248)
   leaf: 0x6809be7 109091815 (73: nrow: 246 rrow: 246)
   leaf: 0x6809be3 109091811 (74: nrow: 246 rrow: 246)
   leaf: 0x6809bdf 109091807 (75: nrow: 246 rrow: 246)
   leaf: 0x6809bdb 109091803 (76: nrow: 246 rrow: 246)
   leaf: 0x6809bd7 109091799 (77: nrow: 246 rrow: 246)
   leaf: 0x6809bd3 109091795 (78: nrow: 246 rrow: 246)
   leaf: 0x6809bcf 109091791 (79: nrow: 246 rrow: 246)
   leaf: 0x6809bcb 109091787 (80: nrow: 246 rrow: 246)
   leaf: 0x6809c06 109091846 (81: nrow: 246 rrow: 246)
   leaf: 0x6809c02 109091842 (82: nrow: 246 rrow: 246)
   leaf: 0x6809bfe 109091838 (83: nrow: 246 rrow: 246)
   leaf: 0x6809bfa 109091834 (84: nrow: 246 rrow: 246)
   leaf: 0x6809ba2 109091746 (85: nrow: 129 rrow: 129)
   leaf: 0x6c07eb5 113278645 (86: nrow: 123 rrow: 123)
   leaf: 0x6809bf6 109091830 (87: nrow: 246 rrow: 246)
   leaf: 0x6809bf2 109091826 (88: nrow: 246 rrow: 246)
   leaf: 0x6809bee 109091822 (89: nrow: 246 rrow: 246)
   leaf: 0x6809bea 109091818 (90: nrow: 246 rrow: 246)
   leaf: 0x6809b9e 109091742 (91: nrow: 246 rrow: 246)
   leaf: 0x6809be6 109091814 (92: nrow: 246 rrow: 246)
   leaf: 0x6809be2 109091810 (93: nrow: 246 rrow: 246)
   leaf: 0x6809bde 109091806 (94: nrow: 246 rrow: 246)
   leaf: 0x6809bda 109091802 (95: nrow: 246 rrow: 246)
   leaf: 0x6809b9a 109091738 (96: nrow: 246 rrow: 246)
   leaf: 0x6809bd6 109091798 (97: nrow: 246 rrow: 246)
   leaf: 0x6809bd2 109091794 (98: nrow: 246 rrow: 246)
----- end tree dump
 
 
index full scan读取的是0x6c07ea0 这个块，而index fast full scan读取的是0x6809b9a这个块也就是包含数据的物理存储位置最前的块。
 
分别看一下这两个块的内容

0x6c07ea0 =十进制的113278624

0x6809b9a =十进制的109091738

 

SQL> select dbms_utility.data_block_address_file(113278624) "file",dbms_utility.data_block_address_block(113278624) "block"  from dual;

      file      block
---------- ----------
        27      32416

 

SQL> select dbms_utility.data_block_address_file(109091738) "file",dbms_utility.data_block_address_block(109091738)"block"  from dual;

      file      block
---------- ----------
        26      39834

alter system dump datafile 27 block 32416;

 

alter system dump datafile 26 block 39834;

 
block 32416的前10行
 
row#0[6564] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 07 11
col 1; len 6; (6):  07 00 7c 20 00 2b
row#1[6578] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 16 4e
col 1; len 6; (6):  07 00 7c 20 00 2a
row#2[6592] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 16 4f
col 1; len 6; (6):  07 00 7c 20 00 29
row#3[6606] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 16 50
col 1; len 6; (6):  07 00 7c 20 00 28
row#4[6620] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 18 02
col 1; len 6; (6):  07 00 7c 20 00 27
row#5[6634] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 23 60
col 1; len 6; (6):  07 00 7c 20 00 26
row#6[6648] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 24 25
col 1; len 6; (6):  07 00 7c 20 00 25
row#7[6662] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 24 28
col 1; len 6; (6):  07 00 7c 20 00 24
row#8[6676] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 28 18
col 1; len 6; (6):  07 00 7c 20 00 23
row#9[6690] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 42 04
col 1; len 6; (6):  07 00 7c 20 00 22
 
 
block 39834的前10行
row#0[4591] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 43
col 1; len 6; (6):  02 81 71 f6 00 36
row#1[4605] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 44
col 1; len 6; (6):  02 81 71 f6 00 35
row#2[4619] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 45
col 1; len 6; (6):  02 81 71 f6 00 34
row#3[4633] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 46
col 1; len 6; (6):  02 81 71 f6 00 33
row#4[4647] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 47
col 1; len 6; (6):  02 81 71 f6 00 32
row#5[4661] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 48
col 1; len 6; (6):  02 81 71 f6 00 31
row#6[4675] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 49
col 1; len 6; (6):  02 81 71 f6 00 30
row#7[4689] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 4a
col 1; len 6; (6):  02 81 71 f6 00 2f
row#8[4703] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 4b
col 1; len 6; (6):  02 81 71 f6 00 2e
row#9[4717] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 4c
col 1; len 6; (6):  02 81 71 f6 00 2d
 
对照一下前面的结果集
 
block 32416的第一行为10616,数据内的存储格式应该为
SQL> select dump(10616,16) from dual;
DUMP(10616,16)
----------------------
Typ=2 Len=4: c3,2,7,11
确实等于dump block所看到的
row#0[6564] flag: -----, lock: 2
col 0; len 4; (4):  c3 02 07 11
col 1; len 6; (6):  07 00 7c 20 00 2b
 
再看block 39834的第1行
SQL> select dump(66266,16) from dual;
DUMP(66266,16)
-----------------------
Typ=2 Len=4: c3,7,3f,43
 
跟dump 的结果也一样
row#0[4591] flag: -----, lock: 2
col 0; len 4; (4):  c3 07 3f 43
col 1; len 6; (6):  02 81 71 f6 00 36
 
这就证明了上面所说的index full scan和index fast full scan的不同。
 
我们也可以用10046事件去跟踪两者走的路径。
SQL> ALTER SESSION SET EVENTS 'immediate trace name flush_cache';（清空buffer cache,以便观看'db file sequential read','db file scattered read'事件）。
SQL> alter session set events'10046 trace name context forever,level 12';
Session altered.
SQL> select object_id from test where rownum<11;
 OBJECT_ID
----------
     66266
     66267
     66268
     66269
     66270
     66271
     66272
     66273
     66274
     66275
10 rows selected.
SQL>  alter session set events'10046 trace name context off';
Session altered.
 
[oracle@csdbc udump]$ grep read cs-dbc_ora_15596.trc
Redo thread mounted by this instance: 1
WAIT #1: nam='db file sequential read' ela= 33 p1=26 p2=39820 p3=1
WAIT #1: nam='db file sequential read' ela= 21 p1=26 p2=39817 p3=1
WAIT #1: nam='db file sequential read' ela= 17 p1=26 p2=39819 p3=1
WAIT #1: nam='db file parallel read' ela= 53 p1=2 p2=2 p3=2
WAIT #1: nam='db file scattered read' ela= 466 p1=26 p2=39821 p3=16
 
最前面的'db file sequential read'是由于读段头等操作，我们来关注'db file scattered read'事件，因为index fast full scan是采用多块读，从39821开始读取db_file_multiblock_read_count个块（本例里设置为16）。我们关心的39834块正位于其中。
 
再来看index full scan的10046 trace
 
SQL> ALTER SESSION SET EVENTS 'immediate trace name flush_cache';（清空buffer cache,以便观看'db file sequential read','db file scattered read'事件）。
SQL> alter session set events'10046 trace name context forever,level 12';
Session altered.

SQL>
 OBJECT_ID
----------
     10616
     12177
     12178
     12179
     12301
     13495
     13536
     13539
     13923
     16503
10 rows selected.
SQL>  alter session set events'10046 trace name context off';
Session altered.
 
[oracle@csdbc udump]$ grep read cs-dbc_ora_15609.trc
Redo thread mounted by this instance: 1
WAIT #1: nam='db file sequential read' ela= 49 p1=26 p2=39821 p3=1
root block,正是先前索引树dump里面的 0x6809b8d
WAIT #1: nam='db file sequential read' ela= 32 p1=26 p2=39830 p3=1
WAIT #1: nam='db file sequential read' ela= 40 p1=27 p2=32449 p3=1
WAIT #1: nam='db file sequential read' ela= 35 p1=27 p2=32445 p3=1
WAIT #1: nam='db file sequential read' ela= 28 p1=27 p2=32433 p3=1
WAIT #1: nam='db file sequential read' ela= 19 p1=27 p2=32429 p3=1
WAIT #1: nam='db file sequential read' ela= 34 p1=27 p2=32425 p3=1
WAIT #1: nam='db file sequential read' ela= 32 p1=27 p2=32421 p3=1
WAIT #1: nam='db file sequential read' ela= 33 p1=27 p2=32417 p3=1
WAIT #1: nam='db file sequential read' ela= 29 p1=27 p2=32413 p3=1
WAIT #1: nam='db file sequential read' ela= 37 p1=27 p2=32409 p3=1
WAIT #1: nam='db file sequential read' ela= 32 p1=27 p2=32405 p3=1
WAIT #1: nam='db file sequential read' ela= 35 p1=27 p2=32401 p3=1
WAIT #1: nam='db file sequential read' ela= 34 p1=27 p2=32397 p3=1
WAIT #1: nam='db file sequential read' ela= 31 p1=27 p2=32456 p3=1
WAIT #1: nam='db file sequential read' ela= 29 p1=27 p2=32452 p3=1
WAIT #1: nam='db file sequential read' ela= 31 p1=27 p2=32448 p3=1
WAIT #1: nam='db file sequential read' ela= 30 p1=27 p2=32444 p3=1
WAIT #1: nam='db file sequential read' ela= 38 p1=26 p2=39858 p3=1
WAIT #1: nam='db file sequential read' ela= 31 p1=27 p2=32440 p3=1
WAIT #1: nam='db file sequential read' ela= 32 p1=27 p2=32436 p3=1
WAIT #1: nam='db file sequential read' ela= 35 p1=27 p2=32432 p3=1
WAIT #1: nam='db file sequential read' ela= 31 p1=27 p2=32428 p3=1
WAIT #1: nam='db file sequential read' ela= 29 p1=26 p2=39854 p3=1
WAIT #1: nam='db file sequential read' ela= 36 p1=27 p2=32424 p3=1
WAIT #1: nam='db file sequential read' ela= 32 p1=27 p2=32420 p3=1
WAIT #1: nam='db file sequential read' ela= 36 p1=27 p2=32416 p3=1
 
index full scan走的路径正是文章开始所提到的定位到root block，然后根据leaf block链表一路读取块。
 
看到这里大家应该比较了解index full scan 和index fast full scan的区别了，最后补充一下index full scan和index fast full scan在排序上的不同。
SQL> set autotrace trace;
SQL> select object_id from test order by object_id;
17837 rows selected.

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=41 Card=17837 Bytes=
          71348)
   1    0   INDEX (FULL SCAN) OF 'IND_TEST_ID' (NON-UNIQUE) (Cost=101
          Card=17837 Bytes=71348)
由于有排序所以oracle自动选择了index full scan避免了排序。
 
那么强制用index fast full scan呢？
 
SQL> select/*+ index_ffs(test ind_test_id)*/object_id from test order by object_id;
17837 rows selected.

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=59 Card=17837 Bytes=
          71348)
   1    0   SORT (ORDER BY) (Cost=59 Card=17837 Bytes=71348)
   2    1     INDEX (FAST FULL SCAN) OF 'IND_TEST_ID' (NON-UNIQUE) (Co
          st=11 Card=17837 Bytes=71348)
index fast full scan会多一步sort order by，相信仔细看过这篇文章的人能知道其中结果了吧，还不知道的人请在文章中自己找答案吧。
关键词(Tag): fast full index scan
阅读18次 评论 个人主页 扔小纸条 文件夹: Oracle
收藏: QQ书签 del.icio.us 订阅: Google 抓虾

功夫熊猫

Robert 发表于 2008-06-26 00:38:54

85分钟, 如果是等人, 我会疯掉, 如果是看一部好玩有意思的电影, 比如功夫熊猫, 感觉很快. 听到一些朋友说这个电影很搞笑, 看过之后, 确实. 除了放松自己, 还有就是想听听成龙大哥和刘玉玲的英语. 可能还是因为他们是华人的缘故, 他们的英语还是很容易的能听出来, 可惜他们两个人的台词总共加起来可能都不超过10句, 100个单词...
今年好莱坞出了两部很有中国元素的电影, 一个是功夫之王, 一个是功夫熊猫. 从故事情节上来说, 虽然一个是真人,一个是动画, 但两者其实走的是一条路子, 更准确的说是好莱坞经典的:毛头小子碰上比同时有100只鸟把屎拉在头上的几率还低的奇遇, 然后被赋予拯救世界的使命, 经过几堂让人看得笑得想哭的速成班然后成功拯救世界. 两部电影身子是好莱坞的, 但穿的都是中国的衣服, 而且感觉功夫熊猫更中国化些. 如果说功夫之王穿的是中山装, 那功夫熊猫穿的就是唐装了. 不去说功夫熊猫中场景里的建筑, 光是那些里面角色穿的衣服就让我觉得很中国. 比如老虎穿的练功服, 鹤头上戴的斗笠.
再说到动作场面, 不知道是不是两部电影都有成龙在里面的原因, 很明显的能看出两部电影走的都是功夫喜剧的路子, 而且更明显的是在功夫熊猫里面的打斗场景, 熊猫很好的并且搞笑的利用了周围的道具来攻击敌人保护自己, 包括使用自己肥硕的屁股. 很明显是成龙的特色.
看到网上有人提议抵制功夫熊猫, 不准咱们的国宝让好莱坞借用了回来赚咱们自己的钱. 真的是没事儿撑的. 有那个精力抵制还不如考问我们自己为什么我们自己的动画片制作者做不出来? 为什么我们只能在一些幼稚的国产动画片中看到一个个神情呆滞的熊猫? 

我不会说我们要感谢功夫熊猫, 但可以肯定的是功夫熊猫, 还有功夫之王类似的电影其实是对我们有积极意义的. 如果留心的话, 可以看到几乎95%的美国电影里面涉及到华人的镜头都是两个模子刻出来了. 一个模子刻出来的是神情呆滞, 蹑手蹑脚, 悄悄走来, 悄悄走去. 另一个模子刻出来的就是内敛得让人想哭, 暴力得让人想跑的打手, 李连杰是很典型的一个. 这些让人觉得中国人是一个不会笑的民族, 是一个你可以经常随便让他加班到2点(勤劳)但开party的时候他只会坐在角落喝茶的民族. 我们是吗? 当然不是! 如果说熊猫是中国的象征, 能让人一想起熊猫就想起中国, 那功夫熊猫里面那只胖胖但却非常可爱的熊猫很直接的告诉人们, 或者说是在向观众传达一个印象, 中国人其实是很开朗, 很有趣, 很容易相处的. 可以说, 功夫熊猫是在一定程度上帮我们宣传, 改变国外人对于我们一种固有的, 不甚好的印象. 当然, 好莱坞可不是中宣部, 他可不是因为这个原因拍功夫熊猫的, Money才是他真正追求的. 所以考虑到他从我们口袋里刮走了那么多票房, 结合两方面考虑, 咱们就算跟好莱坞扯平了, 至少比加勒比海盗要好.

关键词(Tag): 功夫熊猫
阅读30次 评论 个人主页 扔小纸条 文件夹: Essay
收藏: QQ书签 del.icio.us 订阅: Google 抓虾

Error of not passing signature checking while logining QC

Robert 发表于 2008-06-23 23:47:28

Encounter error while logining QC first time:

http://localhost/qcbin/setup_a.cab this file didn't pass signature checking


Execute bellowing command to register capicom.dll:
Regsvr32 C:\Windows\System32\capicom.dll
关键词(Tag): qc
阅读23次 评论 个人主页 扔小纸条
收藏: QQ书签 del.icio.us 订阅: Google 抓虾

割肉之后的涨停...

Robert 发表于 2008-06-22 13:29:40

6/18, 10:15am, 在不堪忍受手中不断缩水的股票, 在conference call中客户aggressive的question的刺激下, 俺割肉了...

10:45am, 大盘开始掉头往上窜了.

3:30pm, 被我割掉的4支股票, 三支涨停, 一支8.6%....

结论: 上班时间真的不能炒股...
阅读17次 评论 个人主页 扔小纸条 文件夹: Business
收藏: QQ书签 del.icio.us 订阅: Google 抓虾

Time...

Robert 发表于 2008-06-21 22:42:46

Dear friends:
To realize the value of ONE YEAR
想知道一整年的价值
ask the student who has failed a class
就去问被当过的学生
To realize the value of ONE MONTH
想知道一个月的价值
ask a mother who gave birth to a premature baby
就去问曾经早产的母亲
To realize the value of ONE WEEK
想知道一个礼拜的价值
ask the editor of a weekly newspaper
就去问周报的编辑
To realize the value of ONE HOUR
想知道一个小时的价值
ask the lovers who are waiting to meet
就去问等待见面的情侣
To realize the value of ONE MINUTE
想知道一分钟的价值
ask a person who missed the train
就去问刚错过火车的人
To realize the value of ONE SECOND
想知道一秒钟的价值
ask a person who just avoided accident
就去问刚闪过一场车祸的人
To realize the value of ONE MILLISECOND
想知道百分之一秒的价值
ask the person who won a silver medel in the Olympics
就去问奥运会银牌的得主
Treasure every moment that you have!
珍惜你所拥有的每一个瞬间
Yesterday is history. Tomorrow is mystery.
昨天已成为历史.明日却依然是谜.
Today is a gift.
今天是珍贵的礼物.
That's why it is called present*!!
那就是它为什么被称作"当下"的原因.
Show your friends how much you care...
让你的朋友知道你有多在乎他们.
阅读22次 评论 个人主页 扔小纸条 文件夹: Essay
收藏: QQ书签 del.icio.us 订阅: Google 抓虾