Windows Live Messenger 多个帐号登录 XP MSN多帐号登陆
作者:admin 日期:2009-08-10
字体大小: 小 中 大
Windows Live Messenger 默认不能同时开多个帐号，MSNShell依旧不支持新版本的MSN，我们只能手动修改注册表来多开MSN了！XP系统下同时登陆多个MSN帐号。
经过测试在WinXP和Vista下均有效：
1、文件方式导入到注册表
打开文本编辑器，比如记事本。将以下代码中的内容拷贝进去，另存为MSNMultiLive.reg，保存。然后双击此文件，将注册表信息合并。
程序代码 程序代码
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Live\Messenger]
"MultipleInstances"=dword:00000001
2、手动修改注册表
其实原理同上，只是手动修改一下。
开始->运行->输入regedit->找到
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Live\Messenger
增加一个新建DWORD值，名为MultipleInstances，数值数据为1。（如下图）
下载文件 点击MSN多用户登录注册表文件
下载后，解压双击即可导入（仅对XP，vista系统有效）
其它方法：[一个是系统自带的。一个是安装的]
一个MSN帐号用:
Windows Messenger 登录 "C:\Program Files\Messenger\msmsgs.exe"
别一个MSN账号用
Windows Live Messenger 登录"C:\Program Files\Windows Live\Messenger\msnmsgr.exe"
原文：How To Enable Polygamy In Windows Live Messenger
Many of you will have several WLIDs, and want to sign into Messenger with more than one of them. Until now you had to seek refuge in a patch or add-on to be able to do so. Not anymore! Microsoft’s John Weisenfeld just shared a little trick with me to enable this, which I’m going to share with you.
The trick involves registry editing, so please follow these steps very carefully:
1. Start regedit (admin)
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Live
3. Right click Messenger and create a new DWORD called MultipleInstances
4. Right click the newly added registry key and choose Modify
5. Set the Value data to 1
6. Close regedit
All done! Now you can launch Windows Live Messenger as many times as you want, and sign in with as many WLIDs you want, on one computer. Just don’t try to sign in with the same WLID more than once on one computer or it will throw error 80071392 at you!
XP本机上运行没有问题，但是终端机上登录一直出现 8000401A 错误，提示服务暂时不可用
Windows Live Messenger 9登录错误8000401A 解决方法：
打开注册表“运行”regedit
HKEY_CLASSES_ROOT\AppID\
下的{380689D0-AFAA-47E6-B80E-A33436FE314B}
将其删除，
关闭注册表编辑器
重新登录。。。。。。O了。
Tuesday, September 15, 2009
Sunday, September 6, 2009
キャッシュフロー重視
■キャッシュフロー重視（会社ポリシーより）
1.キャッシュフローは、企業が存続する上で最も確認しておかなければならない項目人間に空気や水が必要なように、企業は利益がないと倒産する。企業運営をしていく上で必要なものは利益。より正確に表すと、利益＝実際の現金。キャッシュフローを重視するというのは、簡単に言えば今の現金の状態をしっかりチェックするということ。
2.不正行為の抑制会計上の利益ではなく、キャッシュフローを重視するということは、確実な入金がなければならないということであり、架空契約や、会計上の不正は何の意味も持たない。実態のある契約をしなければ入金もないので、キャッシュフローを重視することで、結果として、不正行為の抑止につながる。
■ビジネスモデル（ストック）の徹底（会社ポリシーより）
1経営の安定性・安全性の向上通常、ディストリビューターというのは販売時の粗利や販売手数料が収入源であり、それらはあくまで永続的に入るものではなく一時的にしか発生しないもの。そういった一時的な収入ばかりになると、取引先が撤退すると収入源を一気に失い、会社は倒産する。しかし、ストックがあれば一時的な問題にも余裕をもって対応することができる。即ち、経営の安定性、安全性が増す。
2.「現在の利益」と「将来の利益」の総和が利益現在の利益と将来の利益の総和が本当の利益。現在の利益は今期の営業CF、将来の利益は重要指数（台数、件数など）で見ることができる。よって、短期解約を誘発するような営業手法は一切禁止であり、少しでも中長期に渡ってお付き合い頂ける営業を心掛けなければならない。
キャッシュフローは最終会社利益と存続になりますので、会計の利益は単なる帳簿上の利益です。なので、すべての営業業績は最終にキャッシュフローで評価すべきです。また、一見に難しい問題でも、根底のキャッシュで見るとわかりやすくなることも良くあります。
ビジネスモデル（ストック）はビジネスをやるのに、シナリオと指針です。仕事も生活も指針とシナリオがなければ成功しても偶然です。また、グループのストックは一見に小さいものですが、過去と将来をつながる重要な仕組みです。グループは数回の危機を直面しましたが、ストックがあったこそ、グループは危機を乗り越えて、現在の発展にいりました。
1.キャッシュフローは、企業が存続する上で最も確認しておかなければならない項目人間に空気や水が必要なように、企業は利益がないと倒産する。企業運営をしていく上で必要なものは利益。より正確に表すと、利益＝実際の現金。キャッシュフローを重視するというのは、簡単に言えば今の現金の状態をしっかりチェックするということ。
2.不正行為の抑制会計上の利益ではなく、キャッシュフローを重視するということは、確実な入金がなければならないということであり、架空契約や、会計上の不正は何の意味も持たない。実態のある契約をしなければ入金もないので、キャッシュフローを重視することで、結果として、不正行為の抑止につながる。
■ビジネスモデル（ストック）の徹底（会社ポリシーより）
1経営の安定性・安全性の向上通常、ディストリビューターというのは販売時の粗利や販売手数料が収入源であり、それらはあくまで永続的に入るものではなく一時的にしか発生しないもの。そういった一時的な収入ばかりになると、取引先が撤退すると収入源を一気に失い、会社は倒産する。しかし、ストックがあれば一時的な問題にも余裕をもって対応することができる。即ち、経営の安定性、安全性が増す。
2.「現在の利益」と「将来の利益」の総和が利益現在の利益と将来の利益の総和が本当の利益。現在の利益は今期の営業CF、将来の利益は重要指数（台数、件数など）で見ることができる。よって、短期解約を誘発するような営業手法は一切禁止であり、少しでも中長期に渡ってお付き合い頂ける営業を心掛けなければならない。
キャッシュフローは最終会社利益と存続になりますので、会計の利益は単なる帳簿上の利益です。なので、すべての営業業績は最終にキャッシュフローで評価すべきです。また、一見に難しい問題でも、根底のキャッシュで見るとわかりやすくなることも良くあります。
ビジネスモデル（ストック）はビジネスをやるのに、シナリオと指針です。仕事も生活も指針とシナリオがなければ成功しても偶然です。また、グループのストックは一見に小さいものですが、過去と将来をつながる重要な仕組みです。グループは数回の危機を直面しましたが、ストックがあったこそ、グループは危機を乗り越えて、現在の発展にいりました。
Wednesday, August 26, 2009
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
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
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并成功切换了系统，考虑到他们的数据库繁忙程度和数据库容量非常大，这真是一项伟大的成就。我们可以在以后的数据库版本的升级过程中借鉴他们的方法。
* 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并成功切换了系统，考虑到他们的数据库繁忙程度和数据库容量非常大，这真是一项伟大的成就。我们可以在以后的数据库版本的升级过程中借鉴他们的方法。
Monday, August 24, 2009
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"
/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"
Friday, August 21, 2009
家弓 正彦
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
家弓 正彦
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
Subscribe to:
Posts (Atom)