Windows Live Messenger 多个帐号登录 XP MSN多帐号登陆

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了。

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并成功切换了系统，考虑到他们的数据库繁忙程度和数据库容量非常大，这真是一项伟大的成就。我们可以在以后的数据库版本的升级过程中借鉴他们的方法。

家弓 正彦

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

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

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

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

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

excel 自動曜日計算と色分け

A2セルの値によって、自動曜日計算
=IF(A2="","",CHOOSE(WEEKDAY(A2), "日", "月", "火", "水", "木", "金", "土"))
そして条件付書式で色分けできる。

越媒：中国这招对付越南太高明了

越媒：中国这招对付越南太高明了
凤凰网 2009-07-10 16:31:17
越南新闻网7月7日文章 越南《Dat Viet Daily》报道说，尽管来自中国的进口商品轻而易举地就打入了越南市场，但是越南的出口商品想到达中国市场却非常艰难。


　　越南的报纸最近一直在报道，关于在越南北部与中国交界的地区，等待通过中国海关的卡车，特别是装载农产品的卡车排起了长队的事。根据老街省海关办公室主任阮廷扇所讲，越南出口的农产品，比如腰果、绿豆糕和木薯必须拥有原产地证书并通过严格的质量检查后才被允许进入中国。阮廷扇说，中国一直非常有效地利用关税来调节其进出口。（越南）对华出口的商品，要么接受政府规定的官方关税，要么接受当地政府制定并适用于跨境进口贸易的关税。这解释了为什么在一些情况下，越南向中国出口的鞋类———如果被确认是“正式出口”，必须承受超过30%的税率，但如果这些商品作为“本地贸易”跨境，税率可能会低于5%。

　　中国经常频繁地调整税收政策，这要看其是希望鼓励还是不鼓励某一具体产品的进出口。阮廷扇举了化肥出口这个例子。到6月30日为止，中国对化肥出口实施了130%的出口关税，目的是保证有足够供应用于国内农业生产。然而，一旦中国的国内需求得到满足，它就会大幅度降低出口关税。“中国的进出口政策总是变化非常快且幅度相当大。因此，如果越南的企业不保持足够灵活度，会遭受损失”，越南广宁省芒街市海关办公室主任如是说。

　　与中国交界的越南谅山的一名海关官员说，越南农产品出口经常因卫生检疫受阻，“一些出口产品被拒绝是因为这些产品没按照必需的方式进行包装。举例说，越南的小商户不用箱子来装西瓜，而是用稻草来做衬垫。这是不会被接受的。”

　　越南也应该玩中国的游戏吗？《Dat Viet Daily》就此访问了越南工商部的一名高级官员。这名官员说，中国如今发现把商品出口到大市场变得更加困难了。为应对全球金融危机所带来的影响，中国一直号召国内消费者使用中国制造的商品，开始限制进口，尤其是来自像越南这些周边国家的商品。举例来说，中国制定了新的规定，表面上是为加强对进口的海产品进行卫生检疫。实际上，显然对进口商品制定严格标准是中国调整其贸易平衡和限制进口的一种有效手段。

　　该官员还说，中国对进口产品更加严格的控制当然会降低越南的对华出口量。下降的程度会有多大取决于越南出口产品能在多大程度上满足中国的技术标准和中国实施的标准有多高。

　　一名高级经济学家说，中国控制进口的方法表明，它能够有效地利用世贸组织的规则来保护国内生产者。有报道说约有20个国家正在做着同样的事。然而，越南似乎还没注意到要使用类似的“防御措施”。工商部的统计显示，最近几年来，越南对亚太地区（包括中国）的出口一直占据总出口额的50%。

ガースナー，ルイス Louis V. Gerstner

ガースナー，ルイス　Louis V. Gerstner

ルイス・V・ガースナー
米投資会社カーライル・グループの会長。アメリカ、ニューヨーク州出身。1963年にダートマス大学を卒業。1965年にはハーバード大学ビジネス・スクールでMBAを取得し、マッキンゼー・アンド・カンパニーに入社。その後、アメリカン・エキスプレス、RJRナビスコ会長を務めた。1993年4月、 IBMに初めての外部出身のCEOとして招かれて、2002年12月の退任までに同社の再建に貢献した。


■リーダー育成


かつてのIBMでは、学者と対等に話が出来るような人材が経営者として選抜されていた。しかし、マニュアル通りに同じようなタイプの経営幹部の育成が行われていていたために、社内の官僚主義化は進む一方だった。元々、IBMにはエグゼクティブ・リソース・プログラム（ERP）と呼ぶ全世界統一の経営幹部育成プログラムがあり、早期に人材を発掘し、最終的な経営者育成に向けて計画的に育成する仕組みがあった。


ガースナーは、これを新たに整備し、より明確なリーダーシップ・コンピテンシーを設けて選考を始めた。
企業のリーダーに求められる資質や行動規範を新たに設定し、その要件を次世代のリーダーの選抜・育成を行った。


具体的には、リーダーシップの要件を「勝利への集中」、「実行への体制作り」、「勢いの持続」、「中核」の4分野に大別した。更に、下記の11細目の評価基準を設けた。各細目について、本人・同僚・部下の三者に評価させて現状を把握。その上でライン長からあがる人事データを本社・各国事業所の人事責任者が共有しながら次世代リーダーを選考した。


１．顧客に対する洞察力
２．創造的思考力
３．目標達成への推進力
４．チームリーダーシップ
５．率直さ
６．チームワーク
７．決断力
８．組織構築力
９．コーチング能力
１０．全体への貢献
１１．ビジネスへの情熱


■ガースナーの手がけた改革


ガースナーは、IBMの会長就任当時、徹底的に社内の情勢を調査し、内情を把握した上で当時のIBMの問題点を、ずば抜けた基礎技術力や優秀な人材を抱えていながら、組織が硬直化・肥大化し、ダウンサイジング（小型機への需要シフト）という業界の動向に乗り遅れたことなど、以下の3点に絞って指摘した。


１．官僚主義
２．市場変化への対応の遅さ
３．高コスト構造


IBM再建に当たっては、徹底的なコストカット、非合理の改善などを行う一方で、顧客の望むプロダクトの提供（メインフレームにこだわるのではなく、サービスプロバイダーとしてのIBM）、また官僚主義に対しては社内の組織をフラット化し、チームワークを重視した考え方に基づき、社内風土の改革を徹底的に行った。

サロンA One

サロンA One
http://www.onenext.co.jp/price/index.html

半永久

青山グルメ

青山 カラオケ中西 180
http://www.hotpepper.jp/A_20100/strJ000014078.html
モンテアスルMONTE AZUL 青山 1800 スペイン
http://www.hotpepper.jp/A_20100/strJ000712861.html
http://www.walkerplus.com/cgi-bin/search/bin/search.cgi?static=1&area_m=TO-008&walker=tokyo&cuisine_l=220&cuisine_m=1410

応援のうた

キセキ
エール
ウルフルズ
ワンルーッム・ディスコ

結婚式の歌

http://www.oricon.co.jp/music/special/060614_02.html
http://結婚式の歌.com/00/

オリコンの自社アンケート・パネル【オリコン・モニターリサーチ】にて20代～30代の男女1,200人に“結婚式で歌って欲しいアーティスト”“結婚式で歌いたい、歌って欲しい曲”のインターネット調査を実施。


【自分の結婚式で友達に歌って欲しい曲】
1 乾杯 長渕剛
2 CAN YOU CELEBRATE？ 安室奈美恵
3 Best Friend Kiroro
4 永遠にともに コブクロ
5 結婚闘魂行進曲「マブダチ」 氣志團
6 てんとう虫のサンバ チェリッシュ
7 3月9日 レミオロメン
8 らいおんハート SMAP
9 ハナミズキ 一青窈
10 抱きしめたい Mr.Children


【友達の結婚式で歌ってあげたい曲】
1 乾杯 長渕剛
2 CAN YOU CELEBRATE？ 安室奈美恵
3 てんとう虫のサンバ チェリッシュ
4 Best Friend Kiroro
5 世界に一つだけの花 SMAP
6 Story AI
7 3月9日 レミオロメン
8 ハナミズキ 一青窈
9 永遠にともに コブクロ
10 ハッピーサマーウエディング モーニング娘。


【自分の結婚式で歌って欲しいアーティスト】
1 福山雅治
2 Mr.Children
3 DREAMS COME TRUE
4 安室奈美恵
5 平井堅
6 コブクロ
7 長渕剛
8 浜崎あゆみ
9 aiko
10 KinKi Kids

从中国计算机产业的发展对比一下时代成就

从中国计算机产业的发展对比一下时代成就

送交者: 齐婕 2009年05月08日21:00:10 于 [天下论坛] 发送悄悄话

给个邓时代公布的资料，明眼人一下就能看出哪个时代的水平高，说白了，中国的计算技术在1983年以前是世界三强之一，这段历史是抹杀不了的，否则卫星集成通讯、导弹通信、大型潜艇怎么过关？1986把大型计算机下马，所以出现“1996年国产联想电脑在国内微机市场销售量第一”的可笑成就。

无论现在的邓派拿出多少SCI的paper，其价值比几页纸高不了多少。我们看下列资料：

百度算是改革开放的mp精，它的资料应当对改开派最有说服力：
http://zhidao.baidu.com/question/40443186.html

中国计算机产业的发展

1956年，夏培肃完成了第一台电子计算机运算器和控制器的设计工作，同时编写了中国第一本电子计算机原理讲义。

1957年，哈尔滨工业大学研制成功中国第一台模拟式电子计算机。

1958年，中国第一台计算机--103型通用数字电子计算机研制成功，运行速度每秒1500次。

1959年，中国研制成功104型电子计算机，运算速度每秒1万次。

1960年，中国第一台大型通用电子计算机--107型通用电子数字计算机研制成功。

1963年，中国第一台大型晶体管电子计算机--109机研制成功。

1964年，441B全晶体管计算机研制成功。

1965年，中国第一台百万次集成电路计算机"DJS－Ⅱ"型操作系统编制完成。

1967年，新型晶体管大型通用数字计算机诞生。

1969年，北京大学承接研制百万次集成电路数字电子计算机 --150机。

1970年，中国第一台具有多道程序分时操作系统和标准汇编语言的计算机--441B－Ⅲ型全晶体管计算机研制成功。

1972年，每秒运算11万次的大型集成电路通用数字电子计算机研制成功。

1973年，中国第一台百万次集成电路电子计算机研制成功。

1974年，DJS－130、131、132、135、140、152、153等13个机型先后研制成功。

1976年，DJS－183、184、185、186、1804机研制成功。

1977年，中国第一台微型计算机DJS－050机研制成功。

1979年，中国研制成功每秒运算500万次的集成电路计算机--HDS－9，王选用中国第一台激光照排机排出样书。

1981年，中国研制成功的260机平均运算速度达到每秒100万次。

1983年，"银河Ⅰ号"巨型计算机研制成功，运算速度达每秒1亿次。

1984年，联想集团的前身--新技术发展公司成立，中国出现第一次微机热。

1985年，华光Ⅱ型汉字激光照排系统投入生产性使用。

1986年，中华学习机投入生产。

1987年，第一台国产的286微机--长城286正式推出。

1988年，第一台国产386微机--长城386推出，中国发现首例计算机病毒。

1990年，中国首台高智能计算机--EST／IS4260智能工作站诞生，长城486计算机问世。

1991年，新华社、科技日报、经济日报正式启用汉字激光照排系统。

1992年，中国最大的汉字字符集--6万电脑汉字字库正式建立。

1993年，中国第一台10亿次巨型银河计算机Ⅱ型通过鉴定。

1994年，银河计算机Ⅱ型在国家气象局投入正式运行，用于天气中期预报。

1995年，曙光1000大型机通过鉴定，其峰值可达每秒25亿次。

1996年，国产联想电脑在国内微机市场销售量第一。

1997年，银河－Ⅲ并行巨型计算机研制成功。

1998年，中国微机销量达408万台，国产占有率高达71．9％。

1999年，银河四代巨型机研制成功。

2000年，我国自行研制成功高性能计算机"神威I"，其主要技术指标和性能达到国际先进水平。我国成为继美国、日本之后世界上第三个具备研制高性能计算机能力的国家