UnWarp

http://www.itpub.net/viewthread.php?tid=1154232&extra=page%3D1%26amp%3Bfilter%3Ddigest&page=3
http://www.itpub.net/viewthread.php?tid=1175718&extra=page%3D1&frombbs=1


　在ＯＲＡＣＬＥ９Ｉ下的ＵＮＷＲＡＰ，老外研究得比较彻底了，由于涉及到语法构成分析，比较麻烦，这里就不多说了，
只讲讲在１０到１１Ｇ下怎样搞。在这个版本的ＯＲＡＣＬＥ下，ＵＮＷＲＡＰ的理论依据都来源于
"The oracle hacker's handbook" by David Litchfield
在书中介绍了ＷＲＡＰ后的代码是ＢＡＳＥ６４编码的，也就是说如果我们要ＵＮＷＲＡＰ，首先就要进行ＢＡＳＥ６４
的解码；其次，书中也告诉我们，解码后的每个字节需要根据一个替换表进行单独的替换；替换后的字符串需要按ＬＺ算法
进行解压；最终可以得到源码的明文。是不是挺简单的？如果书上说的是正确的，进行UNWRAP唯一的问题就是这个替换表
了。要得这个替换表，那么我们可以做这样一个假设：
　　　既然我们通过ＳＱＬ可以这样对某过程做DBMS_DDL.WRAP加密可以得到密文，如下所示：
　　　select dbms_ddl.wrap('create procedure a') from dual;
　　　那么对这部份密文的正文部份进行ＢＡＳＥ６４解码的值　与　未加密正文（'procedure a'）直接进行ＬＺ压缩后的值　
必然是一一对应的，且两个串的长度也是相等的。这是一个重大的前提！通过这种假设，肯定就能得到替换表，替换表是按字
节来计算的，所以应该有二个列，其中一列代表ＢＡＳＥ６４解码后的字节值（十六进制００到ＦＦ），另一列代表替换列
（另外提醒一个问题，ＢＡＳＥ６４列不能出现重复值，哈哈，可以想像得到，如果有重复值就完了）。我的意思就是对密文
进行ＢＡＳＥ６４解码后，将对应的密文的正文部份按字节替换成替换表中预先算出来的字节，最后直接按ＬＺ算法进行解压，
替换表正确的情况下，明文就应该出来了。

　　这里需要解释4个问题，密文的正文部份是什么？未加密正文为什么要用'procedure a'而不加上'Create'部份?ＬＺ算法压缩
在ＯＲＡＣＬＥ中怎么办？ＢＡＳＥ６４编码与解码在ＯＲＡＣＬＥ中怎么办？

　　ＢＡＳＥ６４编码地球人都知道，在ＯＲＡＣＬＥ中有现存的工具包进行编码和解码，我们将用到ＢＡＳＥ６４的解码，具体
包是：sys.utl_encode.base64_decode。用的时候还需要另一个过程来将字符串转换为ＲＡＷ格式：sys.utl_raw.cast_to_raw
　　ＬＺ压缩很常见，不过懂得内部算法的人很少，ＯＲＡＣＬＥ中也有现存的工具包，我这里用的是老外的一个ＪＡＶＡ包。在
使用这个ＬＺ工具包时，涉及到一个压缩级别参数，这个等级参数不一样，压缩得到的字符串完全一不样。有人可能要问，这样搞
岂不是没法得到替换表了吗？是的，但也不完全正确。因为可供选择的等级参数有限，俺们还能从０等级开始一个一个进行测试，
看到底哪个参数是ＯＲＡＣＬＥ系统用的来ＷＲＡＰ的。嘿嘿，ＯＲＡＣＬＥ用的是“９”等级。
　　创建过程或包时如果没有ＣＲＥＡＴＥ部份，ＯＲＡＣＬＥ肯定要报错；同样DBMS_DDL.WRAP也不能缺少这个“create”，
否则就要报错。但对于过程或包的ＳＯＵＲＣＥ，查阅系统视图DBA_SOURCE的ＴＥＸＴ列就知道了，肯定没有ＣＲＥＡＴＥ这一句。

　　说到密文的正文部份，首先要看下面的例子：
　　SQL>select dbms_ddl.wrap('create procedure a') from dual;
create procedure a wrapped
a000000
354
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
7
c 38
8BgMHdmA3Qg9IbJmntlZoZQoHwcwg5nnm7+fMr2ywFxakaamb40d1Q=

　　这里要解释一下，加密后的代码中３５４与ＤＢ的版本有关，abcd后的７与创建的对象类型有关，也就是７为存储过程，另外的c 38有其他意义，这里就不多说了。从8BgMH开始，ＢＡＳＥ６４解码后的前二十个字节是SHA1-HASH值（前面那本书说的哈），所以解码后的第二十一个字节开始就是正文了。

　　为了下一节的实践活动，嘿嘿，我们先把ＪＡＶＡ包创建好，用以进行LZ压缩与解压，如下所示（全部用ＳＹＳ用户来做）：
**** 本内容跟帖回复才可浏览 *****

未完待继。。。


创建好了工具，我们先来看看下面的SQL：


with src AS ( select 'PACKAGE a' txt from dual ),
wrap as ( select src.txt , dbms_ddl.wrap( 'create ' || src.txt ) wrap from src ),
subst as (select substr( utl_encode.base64_decode( utl_raw.cast_to_raw(rtrim( substr( wrap.wrap, instr( wrap.wrap, chr( 10 ), 1, 20 ) + 1 ), chr(10) ) ) ), 41 ) x,
amosunwrapper.deflate( wrap.txt || chr(0), 9 ) d
from wrap )
select substr( x, r * 2 - 1, 2 ) c_base64,
substr( d, r * 2 - 1, 2 ) c_translatecode

from subst , ( select rownum r from dual connect by rownum <= ( select length( x ) / 2 from subst ) );

结果如下：

C_BASE64 C_TRANSLATECODE
30 78
83 DA
99 0B
B8 70
F5 74
33 F6
9F 76
F5 74
BF 77
5C 55
5A 48
91 64
A6 00
A6 00
CB 0E
C4 B7
E1 02
48 6E


通过对结果的排序，没有出现同一个ＢＡＳＥ６４编码对应不同的十六进制的情况，因此我们知道了可以用这个ＳＱＬ为基础，通过用不同的ＳＯＵＲＣＥ串来产生替换表的内容。

根据上面的SQL俺就可以写首先建一个表来存储替换表的内容,然后写一段PLSQL块来生成替换表的内容:

SQL>connect sys/XXXX@xxxx as sysdba;

SQL> CREATE TABLE SYS.IDLTRANSLATE
(
C_BASE64DECODE VARCHAR2(2) NOT NULL,
C_LZDEFLATECODE VARCHAR2(2) NULL
)

/


declare
nCnt integer;
nLoop integer;
nSLoop integer;
nCharmax integer;
nCharmin integer;
vChar Varchar2(3);
cursor getchar is
with src AS ( select 'PACKAGE '||vChar txt from dual ),
wrap as ( select src.txt , dbms_ddl.wrap( 'create ' || src.txt ) wrap from src ),
subst as (select substr( utl_encode.base64_decode( utl_raw.cast_to_raw(rtrim( substr( wrap.wrap, instr( wrap.wrap, chr( 10 ), 1, 20 ) + 1 ), chr(10) ) ) ), 41 ) x,
amosunwrapper.deflate( wrap.txt || chr(0), 9 ) d
from wrap )
select substr( x, r * 2 - 1, 2 ) xr ,
substr( d, r * 2 - 1, 2 ) dr
from subst , ( select rownum r from dual connect by rownum <= ( select length( x ) / 2 from subst ) );
begin
nCharmax:=97;
nCharmin:=122;

For nLoop In 97..122 Loop
For nSloop In 0..99 Loop
vChar := chr(nLoop)||to_char(nSloop);
For abc In getchar Loop
Select Count(*) Into nCnt From sys.idltranslate WHERE c_base64decode = abc.xr;
If nCnt < 1 Then
Insert INTO sys.idltranslate VALUES (abc.xr,abc.dr);
Commit;
Else
Select Count(*) Into ncnt From sys.idltranslate WHERE c_base64decode = abc.xr AND c_lzdeflatecode=abc.dr;
If nCnt < 1 Then
DBMS_OUTPUT.PUT_LINE('wrong orginal char:'||vchar||' hex base64:'||abc.xr);
End If;
End If;
End Loop;
End Loop;
End Loop;

end;


运行上面这段ＳＱＬ大概会产生１百多条记录，还未达到00-FF总共256条记录的要求，建议替换

select 'PACKAGE '||vChar txt from dual 中的PACKAGE关健字为procedure或者function类似的，继续运行直到

替换表中有不重复的256条记录为止。

　　有了替换表的内容，还有前面的ＪＡＶＡ工具包和ＯＲＡＣＬＥ工具包，已经无限接近终点了！

　　俺将在后面写一段程序来验证unwrap的威力，矛头嘛就直接指向ORACLE自身的包了。
有趣的研究

将10楼的plsql块改成如下：执行速度更快

set serveroutput on;
Declare
vWrappedtext Varchar2(32767);
vChar Varchar2(2);
vRepchar Varchar2(2);
vLZinflatestr Varchar2(32767);
nLen Integer;
nLoop Integer;
nCnt Integer;
type vartab is table of varchar2(2) index by varchar2(2);

mytbl vartab;
cursor getchar is select C_BASE64DECODE xr,C_LZDEFLATECODE dr from sys.idltranslate;
Begin
for i in getchar loop --sys.idltranslate表内容存到字符数组
mytbl(i.xr):=i.dr;
end loop;
select substr( utl_encode.base64_decode( utl_raw.cast_to_raw(rtrim( substr( TEXT, instr( TEXT, chr( 10 ), 1, 20 ) + 1 ), chr(10) ) ) ), 41 ) x
Into vWrappedtext
from DBA_SOURCE
Where owner='SYS'
And Name = 'DBMS_OUTPUT'
And Type='PACKAGE BODY' ;
--DBMS_OUTPUT.PUT_LINE(vWrappedtext);
nLen := Length(vWrappedtext)/2 - 1;

vLZinflatestr :='';
For nLoop In 0..nLen Loop
vChar := Substrb(vWrappedtext,nLoop*2+1,2);
/*
Select Count(*) Into nCnt From SYS.IDLTRANSLATE Where C_BASE64DECODE=vChar;
If nCnt <> 1 Then
DBMS_OUTPUT.PUT_LINE('SUBSTATION TABLE WARNING: Count not find following char--'||vChar);
Return;
Else
Select C_LZDEFLATECODE Into vRepchar From SYS.IDLTRANSLATE Where C_BASE64DECODE=vChar;
End If;
*/
vLZinflatestr := vLZinflatestr || mytbl(vChar); --从字符数组匹配
--DBMS_OUTPUT.PUT_LINE(vLZinflatestr);
End Loop;
--DBMS_OUTPUT.PUT_LINE(vLZinflatestr);
DBMS_OUTPUT.PUT_LINE(amosunwrapper.inflate(vLZinflatestr));
End;

继续未完的测试哈.废话少说先看代码
set serveroutput on;
Declare
vWrappedtext Varchar2(32767);
vChar Varchar2(2);
vRepchar Varchar2(2);
vLZinflatestr Varchar2(32767);
nLen Integer;
nLoop Integer;
nCnt Integer;
Begin
select substr( utl_encode.base64_decode( utl_raw.cast_to_raw(rtrim( substr( TEXT, instr( TEXT, chr( 10 ), 1, 20 ) + 1 ), chr(10) ) ) ), 41 ) x
Into vWrappedtext
from DBA_SOURCE
Where owner='SYS'
And Name = 'DBMS_MONITOR'
And Type='PACKAGE BODY' ;
--DBMS_OUTPUT.PUT_LINE(vWrappedtext);
nLen := Length(vWrappedtext)/2 - 1;

vLZinflatestr :='';
For nLoop In 0..nLen Loop
vChar := Substrb(vWrappedtext,nLoop*2+1,2);
Select Count(*) Into nCnt From SYS.IDLTRANSLATE Where C_BASE64DECODE=vChar;
If nCnt <> 1 Then
DBMS_OUTPUT.PUT_LINE('SUBSTATION TABLE WARNING: Count not find following char--'||vChar);
Return;
Else
Select C_LZDEFLATECODE Into vRepchar From SYS.IDLTRANSLATE Where C_BASE64DECODE=vChar;
End If;
vLZinflatestr := vLZinflatestr || vRepchar;
--DBMS_OUTPUT.PUT_LINE(vLZinflatestr);
End Loop;
--DBMS_OUTPUT.PUT_LINE(vLZinflatestr);
DBMS_OUTPUT.PUT_LINE(amosunwrapper.inflate(vLZinflatestr));
End;

大家可以看看这个程序的输出是什么？　　ＯＲＡＣＬＥ的系统包没有秘密可言了，当然其他的用了ＷＲＡＰ的应用存储过程与包也对大家没有秘密了．
　　sys.IDLTRANSLATE 的内容，由于牵涉到各方面的因素，我这里就不公开了．相信诸位大大，精通ＰＬＳＱＬ，可以通过对代码的分析，得到替换表的内容；本身不太懂ＳＱＬ的人，得到了这个替换表的内容，我相信也不是什么好事情！
　　精通ＰＬＳＱＬ的人可以发现这个贴子的破解程序只能针对较小的存储过程或包，这是由于多方面的因素，当然我贪图方便是最大的原因．大大们可以根据这个思路，扩展这个程序，将其改造为适应ＳＯＵＲＣＥ长度超过一行，输出长度也大于４０００的应用程序来方便大家使用．

在http://www.itpub.net/1154232.html的基础上

set serveroutput on;
Declare
vWrappedtext Varchar2(32767);
vtrimtext Varchar2(32767);
vChar Varchar2(2);
vRepchar Varchar2(2);
vLZinflatestr Varchar2(32767);
nLen Integer;
nLoop Integer;
nCnt Integer;
type vartab is table of varchar2(2) index by varchar2(2);

mytbl vartab;
cursor getchar is select C_BASE64DECODE xr,C_LZDEFLATECODE dr from sys.idltranslate;
Begin
for i in getchar loop --sys.idltranslate表内容存到字符数组
mytbl(i.xr):=i.dr;
end loop;
vtrimtext:='';
select count(*) into ncnt from DBA_SOURCE
Where owner='SYS'
And Name = 'HANMON'
And Type='PACKAGE BODY' ;
if ncnt >0 and ncnt <5 then
for i in 1..ncnt loop
if i=1 then
select rtrim( substr( TEXT, instr( TEXT, chr( 10 ), 1, 20 ) + 1 ), chr(10) ) --保存去掉换行的BASE64码正文
into vLZinflatestr
from DBA_SOURCE
Where owner='SYS'
And Name = 'HANMON'
And Type='PACKAGE BODY' and line=i;
else
select text into vLZinflatestr
from DBA_SOURCE
Where owner='SYS'
And Name = 'HANMON'
And Type='PACKAGE BODY' and line=i;
end if;
vtrimtext:=vtrimtext||vLZinflatestr;
end loop;
end if;
vtrimtext:=replace(vtrimtext,chr(10),'');
nLen := Length(vtrimtext)/64 ;
vWrappedtext :='';
for i in 0..nLen loop
if i< nLen then
vWrappedtext:=vWrappedtext||utl_encode.base64_decode( utl_raw.cast_to_raw(substrb(vtrimtext,64*i+1 , 64 ))) ;
else
vWrappedtext:=vWrappedtext||utl_encode.base64_decode( utl_raw.cast_to_raw(substrb(vtrimtext,64*i+1 ))) ;
end if;
--DBMS_OUTPUT.PUT_LINE(vWrappedtext);
End Loop;
--vWrappedtext:=substr(vWrappedtext,41);
nLen := Length(vWrappedtext)/2 - 1;

vLZinflatestr :='';

For nLoop In 20..nLen Loop --从第41字节开始
vChar := Substrb(vWrappedtext,nLoop*2+1,2);
/*
Select Count(*) Into nCnt From SYS.IDLTRANSLATE Where C_BASE64DECODE=vChar;
If nCnt <> 1 Then
DBMS_OUTPUT.PUT_LINE('SUBSTATION TABLE WARNING: Count not find following char--'||vChar);
Return;
Else
Select C_LZDEFLATECODE Into vRepchar From SYS.IDLTRANSLATE Where C_BASE64DECODE=vChar;
End If;
*/
vLZinflatestr := vLZinflatestr || mytbl(vChar); --从字符数组匹配
--DBMS_OUTPUT.PUT_LINE(vLZinflatestr);
End Loop;
--DBMS_OUTPUT.PUT_LINE(vLZinflatestr);
DBMS_OUTPUT.PUT_LINE(amosunwrapper.inflate(vLZinflatestr));
End;

附件是解码结果

6月13日修改，不依赖表，用变量存储对照表


code:='3D6585B318DBE287F152AB634BB5A05F7D687B9B24C228678ADEA4261E03EB176F343E7A3FD2A96A0FE935561FB14D1078D97
5F6BC4104816106F9ADD6D5297E869E79E505BA84CC6E278EB05DA8F39FD0A271B858DD2C38994C480755E4538C46B62DA5AF322240DC50C
3A1258B9C16605CCFFD0C981CD4376D3C3A30E86C3147F533DA43C8E35E1994ECE6A39514E09D64FA5915C52FCABB0BDFF297BF0A76B44944
5A1DF0009621807F1A82394FC1A7D70DD1D8FF139370EE5BEFBE09B97772E7B254B72AC7739066200E51EDF87C8F2EF412C62B83CDACCB3B
C44EC069366202AE88FCAA4208A64557D39ABDE1238D924A1189746B91FBFEC901EA1BF7CE';
vLZinflatestr := vLZinflatestr || mytbl(vChar); --从字符数组匹配
替换为
vLZinflatestr := vLZinflatestr ||substr(code,to_number(vChar,'XX')*2+1,2);
新代码code.sql

Oracle CBOの計算方法

Oracle CBOの計算方法
http://www.robios.org/blog/archives/000005.html

コストの計算方法

表全走査 (Full Table Scan):
[ブロック数] / [DB_FILE_MULTIBLOCK_READ_COUNT]

索引一意走査 (Index Unique Scan):
([索引階層数] + 1{ROWIDによる表走査}) * [OPTIMIZER_INDEX_COST_ADJ] / 100

索引範囲走査 (Index Range Scan):
([索引階層数] - 1{リーフ分を控除} + [リーフブロック数] * [Filtering Factor] + [Clustering Factor] * [Filtering Factor]) * [OPTIMIZER_INDEX_COST_ADJ] / 100

ブロック数
表を構成するブロックの総数。ALL_TABLES/DBA_TABLESで確認。
DB_FILE_MULTIBLOCK_READ_COUNT
初期パラメータ。全表走査の際1回の読み取りで何ブロックを同時に取得するか。初期値は8。
索引階層数
B*Tree索引(通常の索引)の階層数。例えば3階層であれば、ルート、ブランチ、リーフ、4階層であれば、ルート、ブランチ、ブランチ、リーフとなる。索引分析後ALL_INDEXES/DBA_INDEXESで確認可能。
リーフ数
B*Tree索引のリーフ総数。最下層ノードの数。
Filtering Factor
全件数に占める、検索取得数の割合。詳細は後述。
Clustering Factor
索引の、それぞれのリーフが参照する表ブロックの総和。索引分析後ALL_INDEXES/DBA_INDEXESで確認可能。詳細は後述。
OPTIMIZER_INDEX_COST_ADJ
初期値は100。詳細は後述。

上記式で、表全走査、索引走査それぞれのコストを計算し(索引が複数あればそれらもそれぞれ計算)、少ない方法にて実行計画を立てる。

Filtering Factor

Filtering Factor (FF) は、取得を行おうとしている件数が全件数の何割か、を示す値である。実際に検索を行っていないため、この値は分析により得られた結果を元に推理される。

表と索引分析後、Oracleがその表と索引に対して既に知っていることは、


* 表の全件数

* 項目の最大値と最小値

* 項目の一意な値の数 (ALL_TAB_COLUMNS等のDISTINCT_KEYS)


である。

索引項目をCOL1、またN、Mを定数(バインド変数ではない)としたとき、FFの値は、検索方法により下記のように決まる。

COL1 = N
FF = 1 / [COL1の一意な値の数]
COL1 > N
FF = (MAX(COL1) - N) / (MAX(COL1) - MIN(COL1))
COL1 < N
FF = (N - MIN(COL1)) / (MAX(COL1) - MIN(COL1))
COL1 between N and M
FF = (M - N) / (MAX(COL1) - MIN(COL1))

例:

表T1の項目COL1には1から10000までの10000件のデータが一意に保存され、索引付けもされている。このとき、MAX(COL1)は10000、MIN(COL1)は1、COL1の一意な値は10000件である。

COL1 = 5000の時、
FF = 1 / 10000 = 0.0001

COL1 > 9000の時、
FF = (10000 - 9000) / (10000 - 1) = 1000 / 9999 = 0.100... = 0.1

COL1 < 9000の時、
FF = (9000 - 1) / (10000 - 1) = 0.899... = 0.9

COL1 between 2000 and 4000の時、
FF = (4000 - 2000) / (10000 - 1) = 0.200... = 0.2

以上の様に、取得が予想される件数の割合を推理することができる。ただし、例に示したような値の分布が均等である項目では推理値は実際の値に非常に近い(若しくは一致する)が、値の分布が非常に偏っている場合は、推理値は実際の値と大きくかけ離れる場合がある。その場合、適当ではない実行計画を立てる等の不都合が起きる。詳細は後述。

ところで、一意な場合のFFはあまり意味をなさない。コストは結局のところ索引階層数 + 1となり、FFの影響を受けないからである。

Clustering Factor

索引のそれぞれのリーフが参照する表ブロックの総和を示す。意味としては、索引を全スキャンした際、いくつの表ブロックにアクセスする必要があるか、という事。Clustering FactorにFiltering Factorを掛けると、索引レンジスキャンした際に、いくつの表ブロックにアクセスする必要があるか、となる。

Clustering Factorは、索引対象の値が表内で分散している場合(例: 1, 2, 3, 1, 2, 3, 1, 2, 3...)、リーフが参照する表ブロックが増えるため、高くなる。逆に、索引対象の値が表内で偏っている場合(例: 1, 1, 1, 2, 2, 2, 3, 3, 3, 3...)、リーフが参照するブロックが少ないため、低くなる。言葉を変えると、同じブロックに索引対象の同じ値が入っていればいるほど、低くなる。

確認は、索引の分析をした後、ALL_INDEXES/DBA_INDEXESのCLUSTERING_FACTORを調べれば可能。

OPTIMIZER_INDEX_COST_ADJ

索引走査における、DBブロック取得コストを調整するパラメータ。1から100(パーセント)をとる。初期値は100、すなわち、調整はしない。

ある環境にて、索引走査にて取得される索引/表ブロックの多数がキャッシュされており、今後もキャッシュされ続けるとする。この時、索引走査での索引/表ブロック取得が、キャッシュヒットにより平均で通常の1/2の時間で可能であれば、索引走査のコスト算出は調整されるべきである。この場合、 OPTIMIZER_INDEX_COST_ADJを50とすることで、1/2に応じた調整が行われる。

OPTIMIZER_INDEX_COST_ADJを使った調整は、索引走査のコストを大きく変化させるため、環境によっては大きなパフォーマンス改善が可能である。ただし、システムパラメータのため、変更の際は十分注意が必要である。

続く...

缩短Oralce升级停机时间

* Transport Database
* MView
* Stream

http://www.itpub.net/thread-1208733-1-1.html

艾玛迪斯全球旅游分销系统公司(Amadeus Global Travel Distribution SA)是全球领先的旅游行业技术及分销供应商。1987年艾玛迪斯总部建立于西班牙马德里。在 Sophia Antipolis(法国尼斯附近)和美国波士顿设立有市场及开发部门。公司的数据中心位于德国慕尼黑附近的Erding。公司提供各种先进的旅游行业技术解决方案，至今已成为成长最快并被最广泛使用的全球分销系统(GDS)。

作为卓越的技术合作伙伴，艾玛迪斯把最先进的信息技术带入旅游行业，使众多的旅游供应商、休闲及商务旅游服务商从中获益。通过设立服务于当地市场的 national marketing companies(NMCs)，艾玛迪斯用其庞大的信息技术资源向全世界200个国家和地区提供优质的技术解决方案。

我们再来看一下跟它们的数据库相关的信息

他们的业务系统达到99.99%的可用率，每秒钟有30万次的数据库请求，每天有2亿8千万次transaction，这是一个相当大的数据库系统，如果用dbua或者exp/imp他们都不能接受升级的风险，于是他们的技术人员就想出了用dataguard和transport tablespace功能来实现最短时间内的安全升级。

具体的实现方法是这样的

1.先为主库建立一个dataguard数据库(可以在线做)

2.在dataguard库上安装10g软件(可以在线做)

3.整理一些不能通过transport tablespace搞定的东西，比如sequence,synonyms,grants......

4.停止主库这边所有write的应用，提供read的服务(写入停止，提供查询)

5.强制归档主库redo log并传到dataguard恢复(写入停止，提供查询)

6.利用transport tablespace来转换数据库版本，并创建sequencee,synonyms,grants等(写入停止，提供查询)。

7.验证新环境的过程，在验证过程中如果发现有问题，则可以切换会原来的系统(写入停止，提供查询)。

8.切换应用到10g数据库（提供服务）

amadeus在演习时做到10分钟内完成4,5,6,7并成功切换了系统，考虑到他们的数据库繁忙程度和数据库容量非常大，这真是一项伟大的成就。我们可以在以后的数据库版本的升级过程中借鉴他们的方法。

Change GTK+ Font to support Internationalize setting

http://developer.pidgin.im
/wiki/Using%20Pidgin#HowdoIchangethefontPidginusesThebackgroundcolor

http://74.125.153.132/search?q=cache:3nQBcxiXhTgJ:d.hatena.ne.jp/dharry/20081118/1227023802+pidgin+font&cd=2&hl=ja&ct=clnk&gl=jp&lr=lang_ja&client=firefox-a

I found the plugin "Pidgin Theme Control" can implement the request too.

As an example, you can put this into .gtkrc-2.0 to change the font size for all GTK+ applications:

# Sets the font used by all gtk applications.
gtk-font-name = "Verdana 9"

Alternatively, you can do this to change the font size for other elements:

# This is the style section. You need this for the examples below.
# If you are going to copy the example, copy the entire block,
# including the "{" and "}" lines.
style "imhtml-fix"
{
font_name = "Sans 10"
}

# This will apply the font style just shown to various components.
# If you are going to copy the example, copy the line that does
# what you want.

# Conversation entry box--where you type.
widget "*pidgin_conv_entry" style "imhtml-fix"

# Conversation history pane--where you read the conversation.
widget "*pidgin_conv_imhtml" style "imhtml-fix"

# Log viewer--where you read stored logs
widget "*pidgin_log_imhtml" style "imhtml-fix"

# formatting-capable entry areas (IMHtml widgets) in request dialogs
widget "*pidgin_request_imhtml" style "imhtml-fix"

# formatting-capable notification areas in dialogs (again, IMHtml widgets)
widget "*pidgin_notify_imhtml" style "imhtml-fix"

家弓 正彦

http://www.insightnow.jp/profile/631

家弓 正彦
KAYUMI, Masahiko
株式会社シナプス 代表取締役
マーケティング戦略を中心としたコンサルティング、マーケティングに特化した教育プログラムの提供を行っています。
株式会社シナプス代表取締役
グロービス経営大学院教授

1959年神奈川県生まれ
松下電器産業株式会社にて、ＦＡ関連機器のマーケティングを担当し、広くマーケティングの現場を経験。その後、三和総合研究所を経て、株式会社シナプスを設立。経営戦略、マーケティング戦略を中心としたコンサルティングに従事。戦略構築から、現場へのインプリメンテーションプラン（導入計画）までをカバーする。同時に、「マーケティング・カレッジ」を立ち上げ、マーケティングに特化したビジネスマン教育事業に取り組む。

共著に、「進化を遂げる組織戦略の行方（SRCレポート）」「日本はこうなる（講談社）」「事業計画書の書き方（日本能率協会）」「デフレに克つ 企業構造改革のすすめ方（日本能率協会）」、その他講演実績は多数。

■オンビジネス
社長業・経営コンサルタント・講師・経営大学院教員といろいろな顔を持つことに愉しさを感じています。そして、より多くのビジネスパーソンにマーケティングの面白さを伝えていきたいですね。

■オフビジネス
海外リゾートでのスキューバダイビング、スーツスタイルやカジュアルファッション、時計、万年筆、ライター、シガー等にこだわりを持っています。
ビジネスとプライベート、どちらもマイペースで疾走します。

どうぞよろしくお願いいたします。

お気に入りに追加
お問い合わせ

ホームページ 仕事術 1位
IT・Web 1位
営業／マーケティング 2位
仕事術 3位
Life ＆ Style 4位
最新の記事
過去の記事一覧を見る タイトル 公開日
MBA教員が見た「伸びる生徒」の５つの特徴 2009年8月14日 18:34
【営業革新４】セールスをマネジメントする 2009年8月12日 18:06
【営業革新３】強いセールスモデルの創り方 2009年8月12日 18:06
【営業革新２】顧客訴求と顧客理解 2009年8月12日 18:05
【営業革新１】セールス活動に入る前に、、、 2009年8月12日 18:05

うつ病

うつ病は心の病気である。そのため、心の癒す労働環境を従業員全員で築くことは何よりもうつ病を防ぐ方法である。また、この環境でもともとうつ病たった方々も安心に働けるようになるため、企業グループに大切な人材を最大限に活かせるようになる。

小心防范：Ｕ盘杀手又出新变种

小心防范：Ｕ盘杀手又出新变种
新华网 2009-08-16 15:35:24
　　中国国家计算机病毒应急处理中心通过对互联网的监测发现，近期出现蠕虫“U盘杀手”新变
种，提醒用户小心防范。

　　专家说，该变种除了继承先前蠕虫通过U盘等可移动存储设备传播等特点之外，还具备了更强的自我保护功能等一些新特点。变种运行后，会自我复制到受感染计算机操作系统的系统目录下，并在该目录多个文件夹中生成不同的可执行病毒文件。变种还会创建具有“系统回收站”属性的文件夹并将其自身的副本复制到其中并隐藏。

　　同时，变种会修改受感染系统的注册表相关键值项，导致操作系统无法正常显示系统隐藏文件、显示可执行文件的扩展名，甚至还会禁止系统中刻录机软件、媒体播放软件以及蓝牙设备等进程的运行。

　　另外，变种会不停地向受感染系统所有磁盘分区的根目录写入变种主程序文件和配置文件，一旦计算机用户点击任意盘符，就会启动运行该变种。该变种还会通过修改系统的注册表启动项，使得变种随计算机系统启动而自动被运行。

　　据专家提醒，已经感染该变种的计算机用户要立即升级系统中的防病毒软件，进行全面杀毒。未感染该变种的计算机用户需打开系统中防病毒软件的“系统监控” 功能，从注册表、系统进程、内存、网络等多方面对各种操作进行主动防御，这样可以第一时间监控未知病毒的入侵活动，达到全方位保护计算机系统安全的目的。

　　此外，用户在使用移动硬盘、U盘等介质时最好先杀毒。同时，最好禁用系统的自动播放功能，防止病毒利用U盘、移动硬盘、MP3等移动存储设备入侵感染计算机操作系统。

在 Mac 下解决 Wii Sports Resort 不能启动的经历

在 Mac 下解决 Wii Sports Resort 不能启动的经历
In Mac, Tools on 30 July 2009 tagged iso, motionplus, wii with no comments

1.收到从淘宝购买的 Wii MotionPlus
2.用 WBFS for MacOS X 把 Wii Sports Resort 美版 ISO 复制到移动硬盘
3.打开 Wii，用 USB Loader GX 启动 Wii Sports Resort，蓝屏，Error #002 错误
4.启用 USB Loader GX 的“防 002 错误”功能，再次启动 Wii Sports Resort，黑屏重启
5.发现需要从 Wii Sports Resort 的光盘镜像里提取一个文件放到 SD 卡根目录，但网上没人提供美版的对应文件 (只有日版和欧版的)
6.发现用来提取文件的 WiiScrubber 只有 Win32 版本
7.找到 WiiScrubber-ng，一个 Unix 移植
8.下载编译 WiiScrubber-ng 的源代码，发现缺少 key.bin 文件无法执行
9.下载 MakeKeyBin 的源代码，提取出跨平台部分单独编译，生成 key.bin
10.运行 wiiscrubber-ng，发现提取文件部分并没有移植
11.少量修改 wiiscrubber-ng, 加入提取文件功能，获得所需的 player.dol 文件
12.复制获得的文件到 SD 卡中，启用 USB Loader GX 的“Alternate DOL”功能，成功进入 Wii Sports Resort, 看完 MotionPlus 的使用演示
13.退出游戏，关闭“Alternate DOL”功能，再次启动 Wii Sports Resort，正式开始游戏

Ｎｏ１

1.その業界で1位になることで、戦いを有利に進めることができる絶対的なシェアを持つことで、取引先との条件交渉が有利に働く。（業界内の権限も持つので、ある程度のルールを決められる）ユーザーからも信用力を得られ契約がとりやすくなる。採用面でも信用力が増すことで採用が効きやすくなる。他のビジネスチャンスも広がる。結果として、1位であれば利益が加速度的に大きくなる。
基本的に業界Ｎｏ１のリーダーは優位になる。なぜなら規模の経済、範囲の経済効果と５Ｆの競争優位が働く。規模の経済は規模の拡大に固定費が比較的に低くなり、労働成熟度が向上することで、労働生産率向上、単位生産物のコスト削減になる。範囲の経済は規模が多角に拡大した場合、いろいろな場面にリソースを再利用できるようになることで、単位生産物のコストが削減され、迅速に大規模な生産体制を作れるようになる。５Ｆの競争優位は業界リーダーになれば、バリューチェーン上の材料（商材を含む）供給者、顧客に比較的に強くなり、良い契約条件、リソースと利益率を獲得できるようになる。また、十分に強ければ、代替製品の研究開発、新規参入者の阻止にスムーズに働く。この強さは一定以上なれば、業界のルールを決めることができる。よく言われているのは、５０％以上なら価格を決める権力が持つようになって、８０％以上であれば完全にである。しかし、Ｎｏ１の目的を忘れてはいけない。

2.大きなマーケット、伸びていくマーケットの中で1位を目指すどんな事業領域でもとりあえず1位を目指せば良いというものではない。業界自体が今後伸びていく業界、そもそもマーケット自体が大きな業界であることが大前提。
大きい、伸びていくマーケット自体はＮｏ１と直接関係がないが、それぞれ単独の事業規模でも大きい当社は小さな業界に参入しても、自身の強みである人員の規模、投資の規模、設備の規模は活かしにくい。また、成長してない分野は既存の強いプレイヤー、つまりが存在する。成長してなければ、投入が高くても、簡単にシェアのバランスを変えることができない。よって、当社の一番適切な分野は大きい、伸びていくマーケットである。

3.従業員に対しても、パートナー企業に対しても、1位を評価する1位になるには何かしらの理由があるわけで、1位と2位を差別化し、1位を評価し、1位に任せていく。なぜ1位を評価するかというと、金メダルと銀メダルではその後の人生に雲泥の差がついてしまうのが世の中であり、そういう世の中に対する理解を日常を通じて促進したい為。（2位以下がダメだということを伝えたいのではなく、世の中がそういうもんだ、ということ）

Business Breakthough というテレビ講座がある 恩蔵先生も出演

http://www.bbt757.com/servlet/content/3058.html

西洋絵画の楽しみ方完全ガイド (単行本)

西洋絵画の楽しみ方完全ガイド (単行本)

国民年金脱退一時金代行サービス

下記の手続きを代行するサービスがあった。

厚生年金の脱退一時金申請
源泉徴収税を還付申告

カリヤ・アンド・アソシエーツ
http://www.k-associates.co.jp/ja/index.html

今日の相談

早稲田IPSの先輩がWBSのMOTを考えていて、相談に来た。
出身は安徽で、北京で仕事８年間してから、日本へきて、国費で５年間をかけて４年もバイトして人工知能博士を取った。
ところで、仕事は３～４ヶ月で、社長は国内の上司だった。今はWebインフラをやっている。社員は１００人ぐらい。
やはり、時間かけてさらに広く知りたいだろうね。

「本のソムリエ」清水克衛さんの江戸川区「読書のすすめ」

夫婦の悩みに聞く一冊 絆の一生
恋愛の悩みに聞く一冊 ビジネス書
君看よう双眼
仕事の悩みに聞く一冊
有什么问题尽管问。大家都是一样走过来的。