亚洲国产另类久久久精品黑人 ,亚洲精华液一二三产区,亚洲中文无码av永久

ntext操作

--text字段增加處理

--創建測試表
create table test(id varchar(3),detail text)
insert into test
select '001','A*B'

--定義添加的的字符串
declare @s_str varchar(8000),@postion int
select @s_str='*C' --要添加的字符串
,@postion=null --追加的位置,null 加在尾部,0 加在首部,其他值則加在指定位置

--字符串添加處理
declare @p varbinary(16)
select @p=textptr(detail) from test where id='001'
updatetext test.detail @p @postion 0 @s_str

--顯示處理結果
select * from test
go

--刪除測試表
drop table test

--text字段的替換處理

--創建數據測試環境
create table test(id varchar(3),txt text)
insert into test
select '001','A*B'
go

--定義替換的字符串
declare @s_str varchar(8000),@d_str varchar(8000)
select @s_str='*' --要替換的字符串
,@d_str='+' --替換成的字符串

--字符串替換處理
declare @p varbinary(16),@postion int,@rplen int
select @p=textptr(txt)
,@rplen=len(@s_str)
,@postion=charindex(@s_str,txt)-1
from test where id='001'

while @postion>0
begin
updatetext test.txt @p @postion @rplen @d_str
select @postion=charindex(@s_str,txt)-1 from test
end

--顯示結果
select * from test

go
--刪除數據測試環境
drop table test

--text字段的添加處理存儲過程--全表

--創建測試表
create table [user](uid int,UserLog text)
create table [order](uid int,state bit)

insert into [user]
select 1,'a'
union all select 2,'b'
union all select 3,'c'

insert into [order]
select 1,1
union all select 2,0
union all select 3,1
go

--處理的存儲過程
CREATE PROCEDURE spUpdateUserLog
@StrLog text,
@State int
AS
--定義游標,循環處理數據
declare @uid int
declare #tb cursor for select a.uid from [user] a join [order] b on a.uid=b.uid
where state=@state

open #tb
fetch next from #tb into @uid
while @@fetch_status=0
begin
--字符串添加處理
declare @p varbinary(16)
select @p=textptr(UserLog) from [user] where uid=@uid
updatetext [user].UserLog @p null 0 @StrLog
fetch next from #tb into @uid
end
close #tb
deallocate #tb
go

--調用示例:
exec spUpdateUserLog '123',1

--顯示處理結果
select * from [user]

go

--刪除測試環境
drop table [user],[order]
drop proc spUpdateUserLog

/*--測試結果

uid       UserLog
----------- ----------
1          a123
2          b
3          c123

（所影響的行數為 3 行）
--*/
--text字段的替換處理--全表替換

--創建數據測試環境
create table test(id varchar(3),txt text)
insert into test
select '001','A*B'
union all select '002','A*B-AA*BB'
go

--定義替換的字符串
declare @s_str varchar(8000),@d_str varchar(8000)
select @s_str='*' --要替換的字符串
,@d_str='+' --替換成的字符串

--定義游標,循環處理數據
declare @id varchar(3)
declare #tb cursor for select id from test
open #tb
fetch next from #tb into @id
while @@fetch_status=0
begin
--字符串替換處理
declare @p varbinary(16),@postion int,@rplen int
select @p=textptr(txt)
,@rplen=len(@s_str)
,@postion=charindex(@s_str,txt)-1
from test where id=@id

while @postion>0
begin
updatetext test.txt @p @postion @rplen @d_str
select @postion=charindex(@s_str,txt)-1 from test where id=@id
end

fetch next from #tb into @id
end
close #tb
deallocate #tb

--顯示結果
select * from test

go
--刪除數據測試環境
drop table test

************************
支持text字段處理的僅有:
下面的函數和語句可以與 ntext、text 或 image 數據一起使用。
函數       語句
DATALENGTH READTEXT
PATINDEX    SET TEXTSIZE
SUBSTRING    UPDATETEXT
TEXTPTR    WRITETEXT
TEXTVALID

1:替換

--創建數據測試環境
create table #tb(aa text)
insert into #tb select 'abc123abc123,asd'

--定義替換的字符串
declare @s_str varchar(8000),@d_str varchar(8000)
select @s_str='123' --要替換的字符串
,@d_str='000' --替換成的字符串

--字符串替換處理
declare @p varbinary(16),@postion int,@rplen int
select @p=textptr(aa),@rplen=len(@s_str),@postion=charindex(@s_str,aa)-1 from #tb
while @postion>0
begin
updatetext #tb.aa @p @postion @rplen @d_str
select @postion=charindex(@s_str,aa)-1 from #tb
end

--顯示結果
select * from #tb

--刪除數據測試環境
drop table #tb

/****************全部替換************************/
DECLARE @ptrval binary(16)
SELECT @ptrval = TEXTPTR(aa)  FROM  #tb  WHERE aa like '%數據2%'
if @ptrval is not null       -- 一定要加上此句，否則若找不到數據下一句就會報錯
UPDATETEXT #tb.aa @ptrval 0 null '數據3'

/****************在字段尾添加**********************************/
--定義添加的的字符串
declare @s_str varchar(8000)
select @s_str='*C' --要添加的字符串
--字符串添加處理
declare @p varbinary(16),@postion int,@rplen int
select @p=textptr(detail) from test where id='001'
updatetext test.detail @p null null @s_str

總結：
1:Text字段類型不能直接用replace函數來替換，必須用updatetext
2:字段比較不能用　where 字段 = ‘某數據’,可以用like來代替
3:updatetext時，若@ptrval值為空會出錯，需注意。

posted @ 2008-09-16 18:07 肖馬輝閱讀(195) | 評論 (0) | 編輯收藏

Sql Server實用操作小技巧集合

19樓互動空間|4LS` F5s

Ld4X7u4nFK r6u0　　包括安裝時提示有掛起的操作、收縮數據庫、壓縮數據庫、轉移數據庫給新用戶以已存在用戶權限、檢查備份集、修復數據庫等

　?。ㄒ唬炱鸩僮?/p>

　　在安裝Sql或sp補丁的時候系統提示之前有掛起的安裝操作，要求重啟，這里往往重啟無用，解決辦法：19樓互動空間 Q]];_H8l
到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager19樓互動空間+J1W @{:F?A} h
刪除PendingFileRenameOperations

　　二）收縮數據庫

--重建索引
&?)PIL-L4S'KF9Cl0DBCC REINDEX19樓互動空間-VQP,sxL mdOe
DBCC INDEXDEFRAG19樓互動空間5eR4Ni&K
--收縮數據和日志
u}l+y&V'{ G%Ed0DBCC SHRINKDB19樓互動空間 x&StK+K8{7q
DBCC SHRINKFILE

　　（三）壓縮數據庫

　　dbcc shrinkdatabase(dbname)

　　四）轉移數據庫給新用戶以已存在用戶權限

exec sp_change_users_login 'update_one','newname','oldname'19樓互動空間3G%V jji0S WdO7M^
go

　?。ㄎ澹z查備份集

RESTORE VERIFYONLY from disk='E:\dvbbs.bak'

　?。┬迯蛿祿?/p>

ALTER DATABASE [dvbbs] SET SINGLE_USER19樓互動空間%m ~+[D KjFB
GO
0Ma7Q)z6B:q0DBCC CHECKDB('dvbbs',repair_allow_data_loss) WITH TABLOCK
'l}.v@7QDu"a8A0GO
!l*a)V0J| RH/d0ALTER DATABASE [dvbbs] SET MULTI_USER
Z&^#rZ#gXt|]0GO

p;}qp#Y'l0--CHECKDB 有3個參數:

--REPAIR_ALLOW_DATA_LOSS

-- 執行由 REPAIR_REBUILD 完成的所有修復，包括對行和頁進行分配和取消分配以改正分配錯誤、結構行或頁的錯誤，以及刪除已損壞的文本對象。這些修復可能會導致一些數據丟失。修復操作可以在用戶事務下完成以允許用戶回滾所做的更改。如果回滾修復，則數據庫仍會含有錯誤，應該從備份進行恢復。如果由于所提供修復等級的緣故遺漏某個錯誤的修復，則將遺漏任何取決于該修復的修復。修復完成后，備份數據庫。19樓互動空間Zor:GjZ
--REPAIR_FAST 進行小的、不耗時的修復操作，如修復非聚集索引中的附加鍵。這些修復可以很快完成，并且不會有丟失數據的危險。

--REPAIR_REBUILD 執行由 REPAIR_FAST 完成的所有修復，包括需要較長時間的修復（如重建索引）。執行這些修復時不會有丟失數據的危險。

--DBCC CHECKDB('dvbbs') with NO_INFOMSGS,PHYSICAL_ONLY

SQL SERVER日志清除的兩種方法
L jR;DcN |0在使用過程中大家經常碰到數據庫日志非常大的情況，在這里介紹了兩種處理方法……

方法一

一般情況下，SQL數據庫的收縮并不能很大程度上減小數據庫大小，其主要作用是收縮日志大小，應當定期進行此操作以免數據庫日志過大

1、設置數據庫模式為簡單模式：打開SQL企業管理器，在控制臺根目錄中依次點開Microsoft SQL Server-->SQL Server組-->雙擊打開你的服務器-->雙擊打開數據庫目錄-->選擇你的數據庫名稱（如論壇數據庫Forum）-->然后點擊右鍵選擇屬性-->選擇選項-->在故障還原的模式中選擇“簡單”，然后按確定保存

2、在當前數據庫上點右鍵，看所有任務中的收縮數據庫，一般里面的默認設置不用調整，直接點確定

3、收縮數據庫完成后，建議將您的數據庫屬性重新設置為標準模式，操作方法同第一點，因為日志在一些異常情況下往往是恢復數據庫的重要依據

方法二

SET NOCOUNT ON
J,P4[3Me{.n:D j0DECLARE @LogicalFileName sysname,19樓互動空間+i8tjMO*s7\g
@MaxMinutes INT,
L@2l4DP bch;`0@NewSize INT

19樓互動空間#~Wx/@M tb%H;A"[\
USE tablename -- 要操作的數據庫名
N4jX ^ z,t^/o;v5^0SELECT @LogicalFileName = 'tablename_log', -- 日志文件名19樓互動空間3|Oae~~ a2C
@MaxMinutes = 10, -- Limit on time allowed to wrap log.19樓互動空間8o5IB u#pd:x G
@NewSize = 1 -- 你想設定的日志文件的大小(M)

-- Setup / initialize
4f5dPR(o)Ph'x-JJ0DECLARE @OriginalSize int19樓互動空間G%BUU8^0~5Y`-Ye
SELECT @OriginalSize = size
O,wq+f2WbC0FROM sysfiles
(GX9?Z ^%W$g0WHERE name = @LogicalFileName
/{k};\ _b%q0SELECT 'Original Size of ' + db_name() + ' LOG is ' +19樓互動空間S&u y2qw#l
CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +
8}Q @.K1L(w0CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
*K8hXUM"Qy%b0FROM sysfiles19樓互動空間7N%w.wV9q
WHERE name = @LogicalFileName
~9i:d4mX0d0CREATE TABLE DummyTrans19樓互動空間\%b$[ D7v7H{
(DummyColumn char (8000) not null)

]sU-x[ y'@k3\}0DECLARE @Counter INT,
B0[4T;\6cd9Je0@StartTime DATETIME,19樓互動空間$W.a'F^ ETK[l
@TruncLog VARCHAR(255)19樓互動空間+F5\3h!`c
SELECT @StartTime = GETDATE(),
j5[*Z T dWO&[$\0@TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'

DBCC SHRINKFILE (@LogicalFileName, @NewSize)19樓互動空間+@s'|'y |+t,d&U
EXEC (@TruncLog)19樓互動空間%C7{R,iP+s NK
-- Wrap the log if necessary.
4s#m @2]W v7c0WHILE @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired
!}&v_Zp+k)R#G-dV F0AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)19樓互動空間 J1KneZ/hy
AND (@OriginalSize * 8 /1024) > @NewSize
:r {Bc`#V0BEGIN -- Outer loop.
h\ YFU4Bh/D5Xv5y6O2S0SELECT @Counter = 019樓互動空間T*NRf8@
WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))19樓互動空間Bj Y1iDTP,P
BEGIN -- update
V B@%K9R/a0INSERT DummyTrans VALUES ('Fill Log')
p)]&` ~C0DELETE DummyTrans
W\-Ns R4LT8h0SELECT @Counter = @Counter + 1
6Msy xWF cf@XC8^_m0END19樓互動空間Yd_ EP,X aW e
EXEC (@TruncLog)
f,ec7[A0{)^0END
#Z5|/|5X9b WY0SELECT 'Final Size of ' + db_name() + ' LOG is ' +19樓互動空間L lQ`%y_
CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
6e"Q\;[!i%xE8bQ0CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
J e%~Kwvr0FROM sysfiles
,Iu&N S @0WHERE name = @LogicalFileName
#C&@#sHB_0DROP TABLE DummyTrans19樓互動空間_,K5yG,S KU
SET NOCOUNT OFF

刪除數據庫中重復數據的幾個方法19樓互動空間[e-C7n^b _
數據庫的使用過程中由于程序方面的問題有時候會碰到重復數據，重復數據導致了數據庫部分設置不能正確設置……

方法一

declare @max integer,@id integer19樓互動空間 Y&`*_9G9M H#t
declare cur_rows cursor local for select 主字段,count(*) from 表名 group by 主字段 having count(*) > 119樓互動空間.y6h^6} RM
open cur_rows
i m)q i2L:Z0fetch cur_rows into @id,@max19樓互動空間C!Ik)w GI;~X
while @@fetch_status=019樓互動空間!\J[!x.T!]
begin19樓互動空間f eC G;f N$S-u
select @max = @max -1
1~$zT$Di7ZFTai:\0set rowcount @max
c8k4f Axh8@ zx0delete from 表名 where 主字段 = @id
K)c0k7P gbP!E@0fetch cur_rows into @id,@max
9[Ri4F Q+|~(?I0end
,d3Tk$Cba0close cur_rows
Y:N*B,Rp&zY0set rowcount 0

方法二

有兩個意義上的重復記錄，一是完全重復的記錄，也即所有字段均重復的記錄，二是部分關鍵字段重復的記錄，比如Name字段重復，而其他字段不一定重復或都重復可以忽略。19樓互動空間&Ae J7?M4]spd
1、對于第一種重復，比較容易解決，使用
w qzC jW+w$w0select distinct * from tableName19樓互動空間 zg8G'jb;k]!u
就可以得到無重復記錄的結果集。19樓互動空間O&F*]B*at8X#]]
如果該表需要刪除重復的記錄（重復記錄保留1條），可以按以下方法刪除19樓互動空間#BK9@4T#B
select distinct * into #Tmp from tableName19樓互動空間/q0AEITHy{[p B
drop table tableName
'}6[5jMUi-b*a0select * into tableName from #Tmp
,y~ ]X#f;R0drop table #Tmp19樓互動空間6}@%r?rn"j`~$C
發生這種重復的原因是表設計不周產生的，增加唯一索引列即可解決。

2、這類重復問題通常要求保留重復記錄中的第一條記錄，操作方法如下
h6p%Y9mN2Xr0Ei~0假設有重復的字段為Name,Address，要求得到這兩個字段唯一的結果集
!p{VE4N'd0select identity(int,1,1) as autoID, * into #Tmp from tableName
o9MI*x+w b GI"F-c0select min(autoID) as autoID into #Tmp2 from #Tmp group by Name,autoID19樓互動空間 m(}R] I ~
select * from #Tmp where autoID in(select autoID from #tmp2)
}J\.Alh!q8~J;r0最后一個select即得到了Name，Address不重復的結果集（但多了一個autoID字段，實際寫時可以寫在select子句中省去此列）

$I&k o#l(WRk l0更改數據庫中表的所屬用戶的兩個方法19樓互動空間_H\Q+DH\
大家可能會經常碰到一個數據庫備份還原到另外一臺機器結果導致所有的表都不能打開了，原因是建表的時候采用了當時的數據庫用戶……

5eN;o U { L2EIvD3@0--更改某個表19樓互動空間6O1C_6F+F2S_
exec sp_changeobjectowner 'tablename','dbo'

19樓互動空間 mX p9qq6sZT0F
--存儲更改全部表19樓互動空間5@u|`2X}
CREATE PROCEDURE dbo.User_ChangeObjectOwnerBatch
E1Q5O JK0@OldOwner as NVARCHAR(128),19樓互動空間T-zuq:x;s"Z9q_
@NewOwner as NVARCHAR(128)
'zC9p*e;HB'|0AS

DECLARE @Name as NVARCHAR(128)19樓互動空間#j"j)},Nu-x
DECLARE @Owner as NVARCHAR(128)
D(f` k9S B"`0DECLARE @OwnerName as NVARCHAR(128)

DECLARE curObject CURSOR FOR19樓互動空間$W!qeIB]%L4n"n
select 'Name' = name,19樓互動空間1X EKG&Q7~'K1LP/D
'Owner' = user_name(uid)
#pG+c{ k!ll0from sysobjects19樓互動空間#vS[@+t:Q u#V
where user_name(uid)=@OldOwner
5z Lyc2}E!a2B$XXz!O0order by name

OPEN curObject19樓互動空間|x5a;}6o-Ip
FETCH NEXT FROM curObject INTO @Name, @Owner
3F6Kz^@m0WHILE(@@FETCH_STATUS=0)19樓互動空間4TZG$?_a7c\b8f7z6b
BEGIN19樓互動空間?;n9Dn)b_Ln{xo
if @Owner=@OldOwner19樓互動空間%~Qa*E^ W|
begin19樓互動空間#iK0nMuDwn
set @OwnerName = @OldOwner + '.' + rtrim(@Name)19樓互動空間u\W"|J:eX+M
exec sp_changeobjectowner @OwnerName, @NewOwner19樓互動空間D~ r&d$X x ^ }4`.r
end19樓互動空間 kg X?*TJ|0|8C
-- select @name,@NewOwner,@OldOwner

FETCH NEXT FROM curObject INTO @Name, @Owner19樓互動空間X)J3m9q!^
END

close curObject
d P9H~ H,`4g!J0deallocate curObject

e je.H z"q0GO

jy(mu ]9[+G K0SQL SERVER中直接循環寫入數據19樓互動空間I.s}/}|7P4O
沒什么好說的了，大家自己看，有時候有點用處

declare @i int
Zu/J0h g3Z;_ k0set @i=1
bmb#d2e| _kk0while @i<30
L\ ~td^[cr0begin19樓互動空間d-w2sx&q:Q"[
insert into test (userid) values(@i)19樓互動空間$AfOv~9rc#i.t
set @i=@i+1
^(G Ggfv?.F0end

無數據庫日志文件恢復數據庫方法兩則
4`/E \%T/P*l0數據庫日志文件的誤刪或別的原因引起數據庫日志的損壞

方法一

1.新建一個同名的數據庫

2.再停掉sql server(注意不要分離數據庫)

3.用原數據庫的數據文件覆蓋掉這個新建的數據庫

4.再重啟sql server

5.此時打開企業管理器時會出現置疑，先不管，執行下面的語句（注意修改其中的數據庫名)

6.完成后一般就可以訪問數據庫中的數據了,這時,數據庫本身一般還要問題,解決辦法是,利用
7`6C rZc};\"i$M0數據庫的腳本創建一個新的數據庫,并將數據導進去就行了.

USE MASTER19樓互動空間6\@mUmJ+u7K
GO

SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
Bm,^mR-z)s~0GO

UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的數據庫名'19樓互動空間r4uR Q I{
Go

sp_dboption '置疑的數據庫名', 'single user', 'true'
v3A3\Q6i ]0Go

DBCC CHECKDB('置疑的數據庫名')
b Q%H}I1r6os0Go

update sysdatabases set status =28 where name='置疑的數據庫名'
*v[$LqXck X0Go

sp_configure 'allow updates', 0 reconfigure with override
9@eyZ l3r;Z0Go

sp_dboption '置疑的數據庫名', 'single user', 'false'
q'~(N)o%X4Lx0Go

方法二

事情的起因
E4ta6O(hE0昨天，系統管理員告訴我，我們一個內部應用數據庫所在的磁盤空間不足了。我注意到數據庫事件日志文件XXX_Data.ldf文件已經增長到了3GB，于是我決意縮小這個日志文件。經過收縮數據庫等操作未果后，我犯了一個自進入行業以來的最大最愚蠢的錯誤：竟然誤刪除了這個日志文件！后來我看到所有論及數據庫恢復的文章上都說道：“無論如何都要保證數據庫日志文件存在，它至關重要”，甚至微軟甚至有一篇KB文章講如何只靠日志文件恢復數據庫的。我真是不知道我那時候是怎么想的？！

這下子壞了！這個數據庫連不上了，企業管理器在它的旁邊寫著“(置疑)”。而且最要命的，這個數據庫從來沒有備份了。我唯一找得到的是遷移半年前的另外一個數據庫服務器，應用倒是能用了，但是少了許多記錄、表和存儲過程。真希望這只是一場噩夢！

沒有效果的恢復步驟19樓互動空間yp s*Y} j1t.B?,euV
附加數據庫
{"plv3x%}3h_0_Rambo講過被刪除日志文件中不存在活動日志時，可以這么做來恢復：

1，分離被置疑的數據庫，可以使用sp_detach_db19樓互動空間w9]#xER,M
2，附加數據庫，可以使用sp_attach_single_file_db

但是，很遺憾，執行之后，SQL Server質疑數據文件和日志文件不符，所以無法附加數據庫數據文件。

DTS數據導出
0\&]q^8|c~*z0不行，無法讀取XXX數據庫，DTS Wizard報告說“初始化上下文發生錯誤”。

緊急模式
V;c^1w e `0怡紅公子講過沒有日志用于恢復時，可以這么做：

1，把數據庫設置為emergency mode

2，重新建立一個log文件

3，把SQL Server 重新啟動一下

4，把應用數據庫設置成單用戶模式

5，做DBCC CHECKDB

6，如果沒有什么大問題就可以把數據庫狀態改回去了，記得別忘了把系統表的修改選項關掉

我實踐了一下，把應用數據庫的數據文件移走，重新建立一個同名的數據庫XXX，然后停掉SQL服務，把原來的數據文件再覆蓋回來。之后，按照怡紅公子的步驟走。

但是，也很遺憾，除了第2步之外，其他步驟執行非常成功?？上В貑QL Server之后，這個應用數據庫仍然是置疑！

不過，讓我欣慰的是，這么做之后，倒是能夠Select數據了，讓我大出一口氣。只不過，組件使用數據庫時，報告說：“發生錯誤：-2147467259,未能在數據庫 'XXX' 中運行 BEGIN TRANSACTION，因為該數據庫處于回避恢復模式。”

最終成功恢復的全部步驟19樓互動空間m%jL_ s ls`L
設置數據庫為緊急模式19樓互動空間v%x}]6Tr6eT
停掉SQL Server服務；

把應用數據庫的數據文件XXX_Data.mdf移走；

重新建立一個同名的數據庫XXX；

停掉SQL服務；

把原來的數據文件再覆蓋回來；

運行以下語句，把該數據庫設置為緊急模式；

運行“Use Master

sp_configure 'allow updates', 1

reconfigure with override

Go”

執行結果：

DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。

已將配置選項 'allow updates' 從 0 改為 1。請運行 RECONFIGURE 語句以安裝。

接著運行“update sysdatabases set status = 32768 where name = 'XXX'”

執行結果：

（所影響的行數為 1 行）

重啟SQL Server服務；

運行以下語句，把應用數據庫設置為Single User模式；

運行“sp_dboption 'XXX', 'single user', 'true'”

執行結果：

命令已成功完成。

ü 做DBCC CHECKDB；

運行“DBCC CHECKDB('XXX')”

執行結果：

'XXX' 的 DBCC 結果。

'sysobjects' 的 DBCC 結果。

對象 'sysobjects' 有 273 行，這些行位于 5 頁中。

'sysindexes' 的 DBCC 結果。

對象 'sysindexes' 有 202 行，這些行位于 7 頁中。

'syscolumns' 的 DBCC 結果。

………

ü 運行以下語句把系統表的修改選項關掉；

運行“sp_resetstatus "XXX"

sp_configure 'allow updates', 0

reconfigure with override

Go”

執行結果：

在 sysdatabases 中更新數據庫 'XXX' 的條目之前，模式 = 0，狀態 = 28（狀態 suspect_bit = 0），

沒有更新 sysdatabases 中的任何行，因為已正確地重置了模式和狀態。沒有錯誤，未進行任何更改。

DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。

已將配置選項 'allow updates' 從 1 改為 0。請運行 RECONFIGURE 語句以安裝。

重新建立另外一個數據庫XXX.Lost；

DTS導出向導
N.l2]7[/v` R'w0運行DTS導出向導；

復制源選擇EmergencyMode的數據庫XXX，導入到XXX.Lost；

選擇“在SQL Server數據庫之間復制對象和數據”，試了多次，好像不行，只是復制過來了所有表結構，但是沒有數據，也沒有視圖和存儲過程，而且DTS向導最后報告復制失??；

所以最后選擇“從源數據庫復制表和視圖”，但是后來發現，這樣總是只能復制一部分表記錄；

于是選擇“用一條查詢指定要傳輸的數據”，缺哪個表記錄，就導哪個；

視圖和存儲過程是執行SQL語句添加的。

維護Sql Server中表的索引19樓互動空間u1g)q5pp!Oo-m;]
在使用和創建數據庫索引中經常會碰到一些問題，在這里可以采用一些另類的方法解決…

--第一步：查看是否需要維護，查看掃描密度/Scan Density是否為100%19樓互動空間(C*c(v5]b|&[O&W9n
declare @table_id int
9?P7v3qC1R w0set @table_id=object_id('表名')19樓互動空間&i ^,p8Xr&J9g/d7HY;_
dbcc showcontig(@table_id)

--第二步:重構表索引
}8k*\lK*V0dbcc dbreindex('表名',pk_索引名,100)

--重做第一步，如發現掃描密度/Scan Density還是小于100%則重構表的所有索引19樓互動空間9D;q0J6C?'a
--楊錚：并不一定能達100%。19樓互動空間vYv&pX
dbcc dbreindex('表名','',100)

B"r)F![j0SQL Server補丁安裝常見問題19樓互動空間#?%xm9KvH8l
誰碰到問題就看看咯：）

一、補丁安裝過程中常見問題

|9_Wp:xF-]*V0如果在安裝補丁的時候遇到如下類似錯誤：

1、安裝過程中出現“以前進行的程序創建了掛起的文件操作，運行安裝程序前，必須重新啟動”，請按照下面步驟解決：

a、重啟機器，再進行安裝，如果發現還有該錯誤，請按下面步驟19樓互動空間#H*Qy-R OB,O)yP
b、在開始->運行中輸入regedit
Py1Jl#i+na0c、到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager 位置19樓互動空間 e BjCK.zN'Zt
d、選擇文件->倒出,保存
0k*Y&yDv-AX0iuo0e、在右邊窗口右擊PendingFileRenameOperations，選擇刪除，然后確認
'u ]f o!z0f、重啟安裝，問題解決

如果還有同樣問題，請檢查其它注冊表中是否有該值存在，如有請刪掉。

19樓互動空間[)Y]4F)^7mC8k
2、在安裝SQL Server SP3，有時候會出現：無論用windows認證還是混和認證，都出現密碼錯誤的情況，這時查看臨時目錄下的sqlsp.out，會發現以下描述：
;eu8XB$d!e)e0[TCP/IP Sockets]Specified SQL server not found.19樓互動空間8h-S\_'RO
[TCP/IP Sockets]ConnectionOpen (Connect()).
z+E*l\ ?7|Ho0其實這是SQL Server SP3的一個小bug，在安裝sp3的時候，沒有監聽tcp/ip端口，可以按照以下步驟進行：

1、打開SQL server客戶器網絡實用工具和服務器網絡工具，確保啟用的協議中包含name pipe，并且位置在第一位.19樓互動空間+fEN)Gp
2、確保[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo]
I&n)ZL?N.Lp X0"DSQUERY"="DBNETLIB".19樓互動空間 x a}c:\
如果沒有，請自己建立
tC4@3e7Z+zR03、停止mssql.19樓互動空間6e"\s} lx%v+Z8N
4、進行安裝.

這樣就可以進行正確安裝了。

二、SQL Server補丁版本的檢查

SQL Server的補丁版本檢查不如Windows 補丁版本檢查直接，一個系統管理員，如果不了解SQL Server版本對應的補丁號，可能也會遇到一點麻煩，因此在這說明一下，通過這樣的辦法判別機器是安全的辦法，不會對系統產生任何影響。19樓互動空間5od&L4|H"|k
1、用Isql或者SQL查詢分析器登錄到SQL Server，如果是用Isql，請在cmd窗口輸入isql -U sa,然后輸入密碼，進入；如果是用SQL查詢分析器，請從程序中啟動，輸入sa和密碼（也可以用windows驗證）。19樓互動空間)Z*Ja5a#~b0{d
2、在ISQL中輸入：
7fKBt*Fl$hN+Bz0Select @@Version；
Yh:VY!j9I-|u7G0go

或者SQL查詢分析器中輸入(其實如果不想輸入，只要打開幫助的關于就可以了:))19樓互動空間)| [A`9t$XEb@
Select @@Version；19樓互動空間6F&A"e$yMT
然后按執行；19樓互動空間!wfSi+a_6T
這時會返回SQL的版本信息，如下：
r7A0U1l&i1@,Sh?0Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.0 (Build 2195: Service Pack 3)
\_L*V c'p0其中的8.00.760就是SQL Server的版本和補丁號。對應關系如下：

8.00.194 －——————SQL Server 2000 RTM19樓互動空間-z/DK-un P4T
8.00.384 －——————(SP1)
NP oWt+\6d)X08.00.534 －——————(SP2)19樓互動空間7Y$A8f qsb5`y
8.00.760 －——————(SP3)

這樣我們就能看到SQL Server的正確版本和補丁號了。

我們也可以用xp_msver看到更詳細的信息

Sql Server數據庫的備份和恢復措施19樓互動空間F"N1p(_o Tt7K
最常用的操作，新手們看看……

一、備份數據庫

1、打開SQL企業管理器，在控制臺根目錄中依次點開Microsoft SQL Server
2FNN&f/M.m+b02、SQL Server組-->雙擊打開你的服務器-->雙擊打開數據庫目錄19樓互動空間(P?)js6v }}*vjs[
3、選擇你的數據庫名稱（如論壇數據庫Forum）-->然后點上面菜單中的工具-->選擇備份數據庫19樓互動空間6_x+us8C$\ s7@![+s:M
4、備份選項選擇完全備份，目的中的備份到如果原來有路徑和名稱則選中名稱點刪除，然后點添加，如果原來沒有路徑和名稱則直接選擇添加，接著指定路徑和文件名，指定后點確定返回備份窗口，接著點確定進行備份

二、還原數據庫

1、打開SQL企業管理器，在控制臺根目錄中依次點開Microsoft SQL Server19樓互動空間xq A Bj)r3u |
2、SQL Server組-->雙擊打開你的服務器-->點圖標欄的新建數據庫圖標，新建數據庫的名字自行取19樓互動空間cwC{"o
3、點擊新建好的數據庫名稱（如論壇數據庫Forum）-->然后點上面菜單中的工具-->選擇恢復數據庫19樓互動空間i9nqA0s r`
4、在彈出來的窗口中的還原選項中選擇從設備-->點選擇設備-->點添加-->然后選擇你的備份文件名-->添加后點確定返回，這時候設備欄應該出現您剛才選擇的數據庫備份文件名，備份號默認為1（如果您對同一個文件做過多次備份，可以點擊備份號旁邊的查看內容，在復選框中選擇最新的一次備份后點確定）-->然后點擊上方常規旁邊的選項按鈕19樓互動空間@%u5B!L#Z d2A$W
5、在出現的窗口中選擇在現有數據庫上強制還原，以及在恢復完成狀態中選擇使數據庫可以繼續運行但無法還原其它事務日志的選項。在窗口的中間部位的將數據庫文件還原為這里要按照你SQL的安裝進行設置（也可以指定自己的目錄），邏輯文件名不需要改動，移至物理文件名要根據你所恢復的機器情況做改動，如您的SQL數據庫裝在D:\Program Files\Microsoft SQL Server\MSSQL\Data，那么就按照您恢復機器的目錄進行相關改動改動，并且最后的文件名最好改成您當前的數據庫名（如原來是bbs_data.mdf，現在的數據庫是forum，就改成forum_data.mdf），日志和數據文件都要按照這樣的方式做相關的改動（日志的文件名是*_log.ldf結尾的），這里的恢復目錄您可以自由設置，前提是該目錄必須存在（如您可以指定d:\sqldata\bbs_data.mdf或者d:\sqldata\bbs_log.ldf），否則恢復將報錯19樓互動空間2c!?%S4oP7u
6、修改完成后，點擊下面的確定進行恢復，這時會出現一個進度條，提示恢復的進度，恢復完成后系統會自動提示成功，如中間提示報錯，請記錄下相關的錯誤內容并詢問對SQL操作比較熟悉的人員，一般的錯誤無非是目錄錯誤或者文件名重復或者文件名錯誤或者空間不夠或者數據庫正在使用中的錯誤，數據庫正在使用的錯誤您可以嘗試關閉所有關于SQL窗口然后重新打開進行恢復操作，如果還提示正在使用的錯誤可以將SQL服務停止然后重起看看，至于上述其它的錯誤一般都能按照錯誤內容做相應改動后即可恢復

三、收縮數據庫

一般情況下，SQL數據庫的收縮并不能很大程度上減小數據庫大小，其主要作用是收縮日志大小，應當定期進行此操作以免數據庫日志過大
i YZJf$@8J1ez4M01、設置數據庫模式為簡單模式：打開SQL企業管理器，在控制臺根目錄中依次點開Microsoft SQL Server-->SQL Server組-->雙擊打開你的服務器-->雙擊打開數據庫目錄-->選擇你的數據庫名稱（如論壇數據庫Forum）-->然后點擊右鍵選擇屬性-->選擇選項-->在故障還原的模式中選擇“簡單”，然后按確定保存19樓互動空間&p _7e6feV5V
2、在當前數據庫上點右鍵，看所有任務中的收縮數據庫，一般里面的默認設置不用調整，直接點確定
P%IELCD`03、收縮數據庫完成后，建議將您的數據庫屬性重新設置為標準模式，操作方法同第一點，因為日志在一些異常情況下往往是恢復數據庫的重要依據

四、設定每日自動備份數據庫

強烈建議有條件的用戶進行此操作！19樓互動空間S@Q"b"P {3@;n#P
1、打開企業管理器，在控制臺根目錄中依次點開Microsoft SQL Server-->SQL Server組-->雙擊打開你的服務器
.bY?,{ llm0t02、然后點上面菜單中的工具-->選擇數據庫維護計劃器19樓互動空間1Y e:\r`;g/L1F
3、下一步選擇要進行自動備份的數據-->下一步更新數據優化信息，這里一般不用做選擇-->下一步檢查數據完整性，也一般不選擇19樓互動空間dx f'asp0C N]
4、下一步指定數據庫維護計劃，默認的是1周備份一次，點擊更改選擇每天備份后點確定
({"}/Gf${:HA05、下一步指定備份的磁盤目錄，選擇指定目錄，如您可以在D盤新建一個目錄如：d:\databak，然后在這里選擇使用此目錄，如果您的數據庫比較多最好選擇為每個數據庫建立子目錄，然后選擇刪除早于多少天前的備份，一般設定4－7天，這看您的具體備份要求，備份文件擴展名一般都是bak就用默認的19樓互動空間 z J/DN!G'^ @ A
6、下一步指定事務日志備份計劃，看您的需要做選擇-->下一步要生成的報表，一般不做選擇-->下一步維護計劃歷史記錄，最好用默認的選項-->下一步完成
\Cf8e*ZU%o07、完成后系統很可能會提示Sql Server Agent服務未啟動，先點確定完成計劃設定，然后找到桌面最右邊狀態欄中的SQL綠色圖標，雙擊點開，在服務中選擇Sql Server Agent，然后點擊運行箭頭，選上下方的當啟動OS時自動啟動服務
5? a)[TP B08、這個時候數據庫計劃已經成功的運行了，他將按照您上面的設置進行自動備份

修改計劃：
4p#AuE-r|$|01、打開企業管理器，在控制臺根目錄中依次點開Microsoft SQL Server-->SQL Server組-->雙擊打開你的服務器-->管理-->數據庫維護計劃-->打開后可看到你設定的計劃，可以進行修改或者刪除操作

五、數據的轉移（新建數據庫或轉移服務器）

一般情況下，最好使用備份和還原操作來進行轉移數據，在特殊情況下，可以用導入導出的方式進行轉移，這里介紹的就是導入導出方式，導入導出方式轉移數據一個作用就是可以在收縮數據庫無效的情況下用來減?。ㄊ湛s）數據庫的大小，本操作默認為您對SQL的操作有一定的了解，如果對其中的部分操作不理解，可以咨詢動網相關人員或者查詢網上資料
R'j:rSP4D01、將原數據庫的所有表、存儲過程導出成一個SQL文件，導出的時候注意在選項中選擇編寫索引腳本和編寫主鍵、外鍵、默認值和檢查約束腳本選項
4R6yi:t?02、新建數據庫，對新建數據庫執行第一步中所建立的SQL文件
(c3yyhR#N;t03、用SQL的導入導出方式，對新數據庫導入原數據庫中的所有表內容

利用數據庫日志恢復數據到時間點的操作19樓互動空間#c%c'_Q.~ [4|jz)G
由于不正常的數據丟失，而又不想使用備份數據還原，只要原來有備份且當前日志保存完好，可以采用這個方法試試，說不定可挽回損失……

1，如果誤操作之前存在一個全庫備份（或已有多個差異備份或增量備份），首先要做的事就是進19樓互動空間2[P1dV)U!p'Bs&}X
進行一次日志備份（如果為了不讓日志文件變大而置trunc. log on chkpt.選項為1那你就死翹了）19樓互動空間t5R$Y B.i#EaH
backup log dbName to disk='fileName'
#p.[cA%tK:YS"|!K02，恢復一個全庫備份，注意需要使用with norecovery，如果還有其他差異或增量備份，則逐個恢
;t\\ujA KM0復19樓互動空間C.n.w4@ Y-S2H"?^
restore database dbName from disk='fileName' with norecovery19樓互動空間1vBH2t {1d@f
3，恢復最后一個日志備份即剛做的日志備份，指定恢復時間點到誤操作之前的時刻19樓互動空間y Y'`GS;Vv
restore log dbName from disk='fileName'19樓互動空間%s(YGzdc)f
with stopat='date_time'

以上這些操作都可以在SQL SERVER企業管理器里完成，難度不大。。。

當然，如果誤操作是一些不記日志的操作比如truncate table，select into等操作，那么是無法利19樓互動空間1K-HgUEQ
用上述方法來恢復數據的...

SQL Server2000數據庫文件損壞時如何恢復
G @-^ N*R\0S\/_$i0出現這樣的問題是比較嚴重的了，能否修復只能看你的運氣……

SQL Server2000中，如果數據庫文件（非系統數據庫文件）遇到錯誤的時候，僅適用于非master,msdb的數據庫。

說明如下：

1 建一個測試數據庫test(數據庫類型為完全)19樓互動空間Ay K?y$KJ4q6C
2 建一個表，插入點記錄
} TS? A7Jm4X\C0create table a(c1 varchar(2))19樓互動空間5\&`0TQ2qvg
go19樓互動空間*xC4i U S-v[@Dg
insert into a values('aa')
r*B ~(mr4T~6O0go
E,J#C H4h0insert into a values('bb')19樓互動空間1z&t1_Ue cz
go
-{S!F Z8R2p}(i8j2h03 作完全備份，到文件test_1.bak19樓互動空間} xI3qx$L.W!i9G-c$yE
4 在作一點修改
9M1C2j`MEWU _6u/I0insert into a values('cc')
9O bL8l2?8u7u/Z0go19樓互動空間%tbCO"D4bN1v"r$B4_
create table b(c1 int)
Hz"Zr+_1AT(g.}0go19樓互動空間Z0}B0`}"f
insert into b values(1)
&L!a X6^t~+`z0go
M$ex,k P AL%G4b0insert into b values(2)19樓互動空間8uH0[ Mq'{m_7T0r1U
go
x_8l `"x05 shutdown 數據庫服務器
,y#T\0x,^ yrU.I Ct06 用ultraedit編輯數據庫文件test_data.mdf,隨便修改點字節內容,相當于數據庫遭到致命的損壞。19樓互動空間6c#fMSEy0u0G
7 啟動數據庫，并且運行企業管理器，點開數據庫，看到test變成灰色，而且顯示置疑。
h |0U SBW_08 運行isql -SLocalhost -Usa -P
ws B8m]'nAP01> backup log test TO DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKUP
+Ax ]L z#X"t%J0est_2.bak' WITH NO_TRUNCATE19樓互動空間V!je*M5co8yTMWSa
2>go19樓互動空間D ~"c3z z'm2T
已處理 2 頁，這些頁屬于數據庫 'test' 的文件 'TEST_Log'（位于文件 1 上）。19樓互動空間 V a8[A6vY
BACKUP LOG 操作成功地處理了 2 頁，花費了 0.111 秒（0.087 MB/秒）。

9 進行恢復最老的完全備份
1e CaD$gX&w01> RESTORE DATABASE test FROM DISK='D:Program FilesMicrosoft SQL ServerMSSQL19樓互動空間HX Z.ow.o
BACKUP est_1.bak' WITH NORECOVERY
(G7M9K.Y1{MsT02> go
,L.x\RI"A.r0已處理 96 頁，這些頁屬于數據庫 'test' 的文件 'TEST_Data'（位于文件 1 上）。19樓互動空間v2i g} [
已處理 1 頁，這些頁屬于數據庫 'test' 的文件 'TEST_Log'（位于文件 1 上）。
|u_;r:h2O_0RESTORE DATABASE 操作成功地處理了 97 頁，花費了 0.107 秒（7.368 MB/秒）。

10 恢復最近的日志
L8};Z'TZ9{"\4c3\01> RESTORE LOG test FROM DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKU
u|4U:_!H)bp S.e*_ n ?0P est_2.bak' WITH RECOVERY
,i#l0Jf(z'f0y02> go
GO9{4nwdh0已處理 2 頁，這些頁屬于數據庫 'test' 的文件 'TEST_Log'（位于文件 1 上）。
#V I8F2ht'n9bxo/L9L0RESTORE LOG 操作成功地處理了 2 頁，花費了 0.056 秒（0.173 MB/秒）。

存儲過程編寫經驗和優化措施
MDj#ah qJ b0f[0經驗之談，看看……

一、適合讀者對象：數據庫開發程序員，數據庫的數據量很多，涉及到對SP（存儲過程）的優化的項目開發人員，對數據庫有濃厚興趣的人。　

　　二、介紹：在數據庫的開發過程中，經常會遇到復雜的業務邏輯和對數據庫的操作，這個時候就會用SP來封裝數據庫操作。如果項目的SP較多，書寫又沒有一定的規范，將會影響以后的系統維護困難和大SP邏輯的難以理解，另外如果數據庫的數據量大或者項目對SP的性能要求很，就會遇到優化的問題，否則速度有可能很慢，經過親身經驗，一個經過優化過的SP要比一個性能差的SP的效率甚至高幾百倍。　

　　三、內容：　

　　1、開發人員如果用到其他庫的Table或View，務必在當前庫中建立View來實現跨庫操作，最好不要直接使用“databse.dbo.table_name”，因為sp_depends不能顯示出該SP所使用的跨庫table或view，不方便校驗?！　?/p>

　　2、開發人員在提交SP前，必須已經使用set showplan on分析過查詢計劃，做過自身的查詢優化檢查。　

　　3、高程序運行效率，優化應用程序，在SP編寫過程中應該注意以下幾點：　　

　　a)SQL的使用規范：

　　　i.　盡量避免大事務操作，慎用holdlock子句，提高系統并發能力。

　　　ii.　盡量避免反復訪問同一張或幾張表，尤其是數據量較大的表，可以考慮先根據條件提取數據到臨時表中，然后再做連接。

　　　iii.　盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那么就應該改寫；如果使用了游標，就要盡量避免在游標循環中再進行表連接的操作。

　　　iv.　注意where字句寫法，必須考慮語句順序，應該根據索引順序、范圍大小來確定條件子句的前后順序，盡可能的讓字段順序與索引順序相一致，范圍從大到小。

　　　v.　不要在where子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

　　　vi.　盡量使用exists代替select count(1)來判斷是否存在記錄，count函數只有在統計表中所有行數時使用，而且count(1)比count(*)更有效率。

　　　vii.　盡量使用“>=”，不要使用“>”。

　　　viii.　注意一些or子句和union子句之間的替換

　　　ix.　注意表之間連接的數據類型，避免不同類型數據之間的連接。

　　　x.　注意存儲過程中參數和數據類型的關系。

　　　xi.　注意insert、update操作的數據量，防止與其他應用沖突。如果數據量超過200個數據頁面（400k），那么系統將會進行鎖升級，頁級鎖會升級成表級鎖。　　

　　b)索引的使用規范：

　　　i.　索引的創建要與應用結合考慮，建議大的OLTP表不要超過6個索引。

　　　ii.　盡可能的使用索引字段作為查詢條件，尤其是聚簇索引，必要時可以通過index index_name來強制指定索引

　　　iii.　避免對大表查詢時進行table scan，必要時考慮新建索引。

　　　iv.　在使用索引字段作為條件時，如果該索引是聯合索引，那么必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引，否則該索引將不會被使用。

　　　v.　要注意索引的維護，周期性重建索引，重新編譯存儲過程?！　?/p>

　　c)tempdb的使用規范：

　　　i.　盡量避免使用distinct、order by、group by、having、join、cumpute，因為這些語句會加重tempdb的負擔。

　　　ii.　避免頻繁創建和刪除臨時表，減少系統表資源的消耗。

　　　iii.　在新建臨時表時，如果一次性插入數據量很大，那么可以使用select into代替create table，避免log，提高速度；如果數據量不大，為了緩和系統表的資源，建議先create table，然后insert。

　　　iv.　如果臨時表的數據量較大，需要建立索引，那么應該將創建臨時表和建立索引的過程放在單獨一個子存儲過程中，這樣才能保證系統能夠很好的使用到該臨時表的索引。

　　　 v.　如果使用到了臨時表，在存儲過程的最后務必將所有的臨時表顯式刪除，先truncate table，然后drop table，這樣可以避免系統表的較長時間鎖定。

　　　 vi.　慎用大的臨時表與其他大表的連接查詢和修改，減低系統表負擔，因為這種操作會在一條語句中多次使用tempdb的系統表?！　?/p>

　　d)合理的算法使用：　　

　　根據上面已提到的SQL優化技術和ASE Tuning手冊中的SQL優化內容,結合實際應用,采用多種算法進行比較,以獲得消耗資源最少、效率最高的方法。具體可用ASE調優命令：set statistics io on, set statistics time on , set showplan on 等。

posted @ 2008-09-01 10:11 肖馬輝閱讀(222) | 評論 (0) | 編輯收藏

求當月最后一天

select datediff(dd,'2008-06-01',dateadd(mm,1,'2008-06-01')

posted @ 2008-08-28 16:12 肖馬輝閱讀(110) | 評論 (0) | 編輯收藏

國內SNS點評

1、小富即安、目光短淺的校內網

在校內開放API之前，我看錯了兩件事情：一個是低估了國內web2.0小網站開發app的熱情；一個是高估了國內SNS網站商業眼光。

校內網在國內能夠成功，我覺得機遇是主要的原因：王興搞校內網的時候，國家教委開始管制各大高校的BBS，在校學生們無處可去，校內網剛好補上，而那些離校的學生面對ChinaRen和5460兩個爛得不能再爛的同學錄，也只能選擇校內網。因此校內網的成功與其說是真人網絡和定位大學生市場的成功，還不如說是國家教委和清華師兄張朝陽賜了王興這個機會。而王興離開校內創辦海內至今沒有起色，也很說明了這個問題，校內的成功不是網站模式的拷貝成功，而是機遇的成功。

BTW：我個人覺得互聯網創業當中的機遇是很重要的，王志東離開新浪以后至今沒有翻身已經很說明問題了。互聯網成功的創業人士離開原來公司獨自創業失敗的例子我手里還有兩個，因為認識就不方便點名了。總之，成功的人不要覺得自己很了不起，你的成功多半是走了狗屎運。我到很佩服馬化騰和丁磊，從不諱言自己是走了狗屎運的。

校內網本質不是Facebook模式，而是社區網站，雖然他也做了必要的隔離，但是總體而已，UGC在校內還是占了很重要的部分，特別是校內和mop整合的很緊密。我看過王興創辦海內的一個采訪：記者問他為什么創辦海內，他說校內網雖然抄襲Facebook，但是本質上還是抄襲MySpace的，而他更看好Facebook，所以創辦海內，真正抄襲Facebook。這段話我當時不理解，但是后來我明白了，你仔細研究校內網，他的確是一個披了Facebook皮的MySpace網站，他的社區性質很明顯。

校內的社區性質決定了他絕不會走Facebook的商業模式，為什么呢？如果你像我一樣自己辛辛苦苦創辦了一個社區網站，積累了這么多會員出來，那么你絕對沒有開放網站、開放用戶的決心。因為這樣一個社區已經可以讓你真金白銀的賺很多錢了，如果你現在徹徹底底的轉型搞應用平臺，等于是放棄了現在可以觸手可及的利益，而去博一個更偉大的賭注?；蛘哂梦鋫b小說的典故來形容就是，你想修煉吸星大法絕世神功的話，就必須先把自己辛苦練了二十年的內功廢掉，你說除非逼到絕路，誰會愿意冒這個險？

校內的兩難困境就在這里，不過對于陳一舟來說，他一點不為難，因為他是一個連眼前利益都不肯放棄的人。所以校內的霸王條款一點都不奇怪，奇怪的只是把別人當傻瓜這究竟是自己的智商問題，還是別人的智商問題呢？

不過坦白說，校內現在的條件很好，積累了足夠多的用戶，又融了4.5億美元的資金，完全有資格去做平臺，而不必擔心什么風險，更何況國內web2.0小網站空前高漲的app開發熱情和淘寶網的經驗也證明了Facebook的商業戰略在中國完全有實現的可能性。但是以陳一舟的性格和現在校內網的做法，我可以斷定校內會親自切入若干垂直領域，例如電子商務，旅游，網絡招聘，web網游，在賺那么丁點小錢的同時，放棄了成為真正的中國Facebook的可能性。我想，如果把陳一舟換成了馬云，馬云一定會選擇走平臺的道路，所以說性格決定命運呀。

2、命運難測的開心網

前面說了開心網是真正氣質上符合Facebook克隆的網站，實際上開心網成功的唯一秘訣就是抄襲Facebook抄的最謙虛，最真誠，抄到了位。開心網最火的買賣朋友和爭車位這兩個應用都是抄襲自Facebook的“Friends for sale”和“Parking War”，號稱開心網貼心的注冊后提示郵箱登錄鏈接，其實也是原封不動的抄了Facebook。而開心網不過是忠實的抄襲了Facebook就已經驚人的成功了，由此可見國內互聯網的作弊家們，給點專業精神好不好，你抄也得抄像點嘛。

開心網唯一的問題就是商業模式，CPC廣告在國內更加行不通，如果說Facebook還能用CPC賺到1.45億的話，那么開心壓根就不用指望廣告費。如果走Facebook的平臺戰略，構建一個巨大的應用平臺，通過app商家來收費的話，這條路太長了，需要的投資太大。馬云的成功畢竟也有孫正義和Yahoo累計十多億美元的砸錢。孫正義已經給陳一舟砸了4.5億了，不可能再給開心網了。

所以我猜測開心網的商業模式會走第三條路，就是自己做web小游戲，最終轉型成為一個SNS型的休閑web網絡游戲網站。但是這條路會走的很累：一是web網游市場競爭的激烈程度完全不低于SNS網站；二是純做小游戲的開發成本很高。

目前開心網的小游戲都是自己開發的，但是這種小游戲是有一個新鮮期的，用戶一開始玩活躍度很高，但是過了新鮮期，就逐漸覺得沒有意思了，用戶經過了一段時間的活躍期，就會逐漸消沉下去，開心網現在已經開始出現這種問題了。所以傳統網游的生命周期即便不斷更新也不過3-5年而已，這種web小游戲的生命周期就更短了，不過1-3個月而已。你要保持網站用戶的活躍度，就要不停的開發下去，因此開發成本會越來越高。

Facebook最聰明的地方就是他自己不開發app，只鼓勵app開發商去開發，因此Facebook沒有這個開發成本的巨大負擔。開心網要想擺脫這個困境，還是必須走Facebook平臺戰略，可以說開心不走平臺戰略就沒有大的前途，但是開心要走平臺戰略，這個目標就太大，實現難度過高。所以Facebook的模式不是那么容易抄的，你真想做Facebook的話，你不開放平臺是根本玩不下去的，但你開放平臺你沒有足夠的資金支撐，你也玩不下去。

3、失敗的海內網

王興現在的處境很尷尬。王興創辦海內網的時候，已經意識到要避免成為一個社區網站了，但是由于他一開始沒有從app切入，導致了海內以他不期望的方式成為了一個IT同人社區了。但是他又非常不愿意接受這一點，極力擺脫。不過他不做IT同人社區，有的是人做，于是5GSNS出來了，海內上面的大批IT大牛都跑了。不知道現在王興究竟是高興多一點，還是失落多一點呢。

海內網和下面要提到的所有SNS克隆網站相比，有一個本質不同：海內不提供網站公共信息的廣播，你看不到朋友之外的信息，他還是以Facebook那種模式，引導你去和自己熟人去社交。但不幸的是海內的用戶們畢竟是在中國BBS泡大的一代，你不用app去勾引他們，他們在海內只想著臥底發文搞UGC，而不是拉自己的哥們上來虛情假意的社交。失敗，這真的是很失敗呀。

4、畫虎類犬的UCHome、一起、螞蟻、5GSNS等等

一言以蔽之，這些網站的創始人心里都有一個執念：“BBS是可恥的，BBS是沒有商業價值的，BBS是沒品的，我作為一個有品的互聯網資深人士，我得創造有品的互聯網生活方式”

小戴同學在discuz!論壇上面寫了很長的一篇帖子（不過比我這篇文章短），講他為什么要開發UCHome，中心思想就是BBS過時了，BBS缺點太大，我發現Facebook做社區比BBS更優越，所以我現在開發了UCHome。

謝文就不用說了，一直鼓吹他的三個代表精神：代表互聯網的物質生活，代表互聯網的精神生活，代表互聯網的社會生活的一個超級web2.0社區，不知道他還有沒有八榮八恥？總之謝文導師明槍明棒的要搞社區，結果卻套了一個Facebook的皮上來。其實您大可不必，你要是不抄Facebook的皮，我就把你和豆瓣、51.com放在一起看了。這搞的不倫不類的，還不如光明正大的說我要抄Facebook呢，何必呢？自己都沒有搞清楚自己要干啥的人。

麥田師兄比謝導師還沒方向感，整天琢磨poke小藥丸去了。我記得麥田說過一句話，說他之所以搞螞蟻，就是因為他太煩BBS了，麥田的優點就是太天真，天真的隨便講真話。

5GSNS這個就不說，還不如用discuz!得了。

那么他們為什么要用Facebook的皮來做社區呢？

1、BBS的確有很大的缺陷
凡是運營過BBS的人都知道BBS的“劣幣驅逐良幣”的問題，低手充斥會導致高手的離開、社區的衰落。用Facebook的皮可以很大程度上隔離用戶，解決BBS最大的痼疾。

2、可以改進很多BBS沒有做好的功能
比方說集中的信息更新通知功能，個性化推薦，更好的社區好友互動功能等等。

這些好處都是看得見的，再加上很多人本身對BBS的強烈排斥，更加傾向于用Facebook之皮來做社區網站了。我得必須承認，雖然UCHome這個克隆完全曲解了Facebook之本意，但是UCHome也不失為一個不錯的改良版本的社區軟件。

但是我得說，作為一個非盈利性質的社區來說，用UCHome可能比BBS更好，但是對于一個有商業期望的網站來說，用UCHome做社區，無疑于自殺。為什么呢？

因為Facebook之皮本身是用來實現熟人之間的社交的，因此他是一個封閉的工具，非常不利于信息的傳播！

傳統的BBS要盈利，已經有兩條被證明過康莊大道：

1、BBS轉型做網絡媒體，以BBS為基礎成為網絡媒體的成功案例簡直多得數不過來：

新浪網的前身就是一個四通利方體育沙龍BBS；
網易的前身也是一個大BBS，我在98年還注冊過賬號灌水；
IT媒體類的網站，最近被收購的IT168，PCPOP哪個不是靠BBS起家的？太平洋電腦網也是BBS起家；
CSDN也是BBS起家，一開始是程序員大本營光盤的技術支持論壇；
被IT168買過去的ITPUB，ChinaUnix也是BBS；
JavaEye也是BBS起家；

2、BBS轉型做電子商務

阿里巴巴網站一開始就是一個BBS，是馬云親自敲定要做BBS的；
籬笆網也是BBS，不用說了；
搜房網也是BBS起家

BBS起家的互聯網網站太多了，這本來就是一條光明的大道。為什么這些互聯網資深人士畏之如虎呢？

1、BBS的運營難度和成本都比較高
要運營好一個BBS，站長需要非常高超的平衡能力，以及一個得力的運營團隊，能把一個BBS運營好是極難的事情，這里面的門檻非常高，太多人想回避這個難度走捷徑，造假，灌水，吵做，流量是上來了，社區的商業價值沒有了。而且BBS需要持續不斷的投入，一旦運營投入不足，BBS的人氣就難以為繼。

2、越是互聯網資深人士越希望用網站獨特的功能取勝，不戰而屈人之兵，越想避免商業上的短兵相接和踏實的運營。
對互聯網特別有感覺的人，往往希望用自己的長處作為核心競爭力，希望用卓越的網站功能和體驗去吸引用戶，戰勝對手，而不屑于沒有技術含量的日常運營工作和類似傳統銷售的營銷方式。我感覺自己身上就存在這樣的毛病，而且我也從上述很多人的言論當中感受到了這一點。網站畢竟是公司，要遵守商業規則，踏踏實實的運營和賺錢比整天想著用殺手锏網站功能去擊敗對手更重要。

而且我也強烈的感覺到一點：走捷徑成功的網站往往商業模式會難產，一點一點打拼上來的網站商業模式都是順理成章的。上面提到這么多從BBS起家的網站哪個不是踏踏實實運營了五六年以后成功的？而2005年風光無限的博客網站現在紛紛倒閉，博客網站的運營難度根本無法和BBS相比，因此催生商業模式也更難。

用Facebook之皮運營的社區網站，其用戶創造內容的傳播途徑是受阻的，因此無法成功的轉型成為一個網絡媒體，這BBS第一條商業模式就堵死了；其做電子商務網站其用戶傳播的途徑又受限于朋友之內，傳播范圍太小，無法形成有效營銷，這BBS第二條商業模式也堵死了。5GSNS要搞網絡招聘，但是網絡招聘市場的水非常深，我可以告訴大家的就是：截止目前為止，所有的垂直招聘社區無一成功的，5GSNS在走一條沒有商業前途的路，真要搞招聘，不能按照5GSNS現在這種搞法。

六、社區網站做SNS

Facebook的前景是光明的，但是中國能不能出一個Facebook，現在看來并不是那么樂觀。

大多數披著Facebook皮的社區網站都是瞎湊熱鬧，如果作為興趣愛好搞搞Facebook之皮類型的社區網站，玩玩也好，但是要想搞一個有商業前景的社區網站，我奉勸一句，還是別用UCHome，這是一條死路。

另外還有一個有意思的趨勢：一些以BBS起家的社區網站也開始SNS化，開始引入Facebook模式：

一個是TechWeb用UCHome架設了一個社區，這個我就覺得很搞笑了，明明有自己的BBS，還搞UCHome自己搶自己的用戶？

另外一個稍微高明一點，CSDN把個人空間和個人博客改用Facebook之皮來實現了。其實這層皮并不重要，重要的是你怎么給社區的用戶提供好的個性化推薦、好的個人信息聚合、好的朋友交流工具，這些我在CSDN個人空間尚未看到。

七、SNS之我見

國內真正在做SNS的網站并不多，SNS這條也不好走，但如果能成功，就是一個the big thing，但是還看不出來候選者。

那些批著Facebook之皮的社區網站，我預測將有一半以上在兩年之內死掉，另外一半會改回BBS。

社區網站做SNS悠著點好，先想清楚了再做，要做就做得有點創新，別蠻干，上來就扒別人的按鈕和CSS。 SNS是2008年中國互聯網最火爆的現象了，無數的SNS網站一夜之間紛紛涌現，前仆后繼，慰為壯觀：校內、海內、開心、一起、螞蟻以及無數的Facebook克隆SNS網站陷入了一場空前慘烈的廝殺當中，每個人都生怕錯過互聯網下一個the big thing的機會，一波接一波的抄襲、炒做和競爭令人應接不暇、眼花繚亂。我也未能免俗，從2006年就一直關注SNS網站的發展，在2007年下半年就開始用Facebook，也一直在不斷思索：究竟SNS網站的未來是什么呢？這場空前混亂的SNS大戰會有什么樣的結果呢？在中國，一個成功的SNS模式應該是什么樣的呢？先闡述一下自己的觀點，期待拋磚引玉：

一、引子

早在博客概念還如日中天的2005年，國內就已經有一大批克隆MySpace的SNS網站了，比方說uuzone，圈網等等，當2006年MySpace以5.8億美元的高價被新聞集團收購之后，國內的Myspace克隆網站達到了一個高潮。但是這種類型的SNS網站模式在國內一直不太成功，難以病毒式傳播，需要依靠大規模用戶推廣和不斷的線下活動組織，所以逐漸式微了。除了已經關門的之外，其他的已經無一例外的改頭換面克隆Facebook了。此時當其他網站還在盯著博客概念和MySpace的時候，王興已經全盤克隆Facebook推出了校內網，眼光很獨到。

但是直到2007年微軟以2.4億美元購買了Facebook的1.5％股份，這才真正引爆了國內的Facebook熱潮，此前言必稱MySpace的謝文也從此改口，言必稱Facebook了。從2007到現在一年時間不到，國內的Facebook克隆SNS網站已經是忽如一夜VC來，千萬SNS繽紛開了。這些眾多的SNS網站當中，除了51.com和豆瓣之外，幾乎無一例外的先后抄襲MySpace和Facebook，特別是從王興開始，把抄襲發展到了毫無道德底線的程度：連按鈕和CSS樣式表都直接拿來就用，開創了互聯網抄襲無底褲的新時代，從中國互聯網的歷史貢獻來說，王興可以和周鴻祎相提并論，都是劃時代的開創者。

現在的SNS都長著一副Facebook的嘴臉，這真的十分無趣，國外的Web2.0網站類型非常豐富，光是SNS類型的還有twitter，friendfeed，friendster，ning等等，干嗎光盯著Facebook抄阿？所以我的第一個話題是：

二、Facebook的成功秘訣是什么？

這幾年時不時有人問我：JavaEye的成功秘訣是什么？也有很多人告訴我他們發現了JavaEye成功的秘密是XXX，在他們看來，只要按照這個XXX去做，也可以創辦一個成功的技術網站，但我沒有發現有人成功過：這不是因為他們找錯了秘訣，而是因為網站的成功并不是光靠一個秘訣。

JavaEye的發展歷史分為幾個階段：從2003年9月創立到2006年8月是第一個階段，這個階段的JavaEye靠的是個人鐵腕管理；從2006年9月到2007年9月是第二個階段，這個階段的JavaEye靠的是web2.0概念的社區改造；從2007年10月開始是第三個階段，這個階段的JavaEye靠的是不斷精益求精的功能和品質服務。以后JavaEye還會有很多發展階段，跨越每個不同的發展階段都需要獨特的核心競爭力（或者說秘訣）。

現在國內克隆Facebook的一些SNS網站就犯了上面同樣的問題：王興認為Facebook的成功秘訣是發展大學生用戶市場，所以他搞了校內網；當王興賣掉校內創辦海內的時候，他又認為Facebook的成功秘訣是真人社區，這一點也被謝文反復的吹捧；而戴志康顯然認為Facebook的成功秘訣是去中心化的社區形態，所以他搞了一個UCenter Home出來；而從開心網開始，大家又突然發現Facebook的成功秘訣原來是上面的Web小游戲，于是一窩蜂的抄襲Facebook的熱門小游戲；當然還有很多人認為Facebook的成功秘訣在于開放平臺；不過最搞笑的還是麥田師兄（他是我大學同系高4屆的學長），把一個poke功能當成了Facebook成功的全部秘密，很有點像古代學會寫一二三，就以為“萬”字要寫一萬筆的笨學生。所以不同的人看Facebook，會得出不同的結論，所謂：“橫看成嶺側成峰，遠近高低各不同”。

其實這些看法都對，但是又都不準確：Facebook在每個發展階段都有導致他成功的原因：在Facebook發展的第一個階段，面向校園市場和實名注冊是他成功的原因；在Facebook發展的第二個階段，采用去中心化的封閉式設計又能夠很好的隔離不同類型的用戶；在Facebook發展的第三個階段，是開放平臺推動了他的騰飛，是web小游戲讓他的用戶群迅速的擴大。因此就算要抄襲Facebook，也應該認識到Facebook成功的每個階段，要抄就抄得全面點，別把著一個poke就以為自己得到了成仙藥丸。

三、Facebook究竟是什么？

那么Facebook本質上是什么東西呢？現在的Facebook對用戶來說是一個社交工具，而不是一個社區；如果我們拋開用戶的身份，從互聯網網站類型去看，Facebook是一個應用平臺，而不是一個社區網站。因此目前國內的SNS網站當中，只有開心網最接近Facebook，只有開心和海內沒有企圖去成為一個社區網站，其他所有的SNS網站都背離了這一點。

我在2007年下半年，總是不斷的收到一些朋友的Facebook郵件邀請，一開始不為所動，到后來開始不勝其擾，最后注冊了一個賬號。但是注冊賬號以后發現Facebook就是一個空白的網站，根本不知道可以干嗎，于是又是長期的不登陸，直到一個朋友給我發來了Facebook上面的Vampire的app邀請，Vampire是一個吸血鬼的小游戲，你可以咬別人組建你的吸血鬼軍隊，還可以和別的軍隊作戰。就這么一個小游戲，立馬讓我明白了Facebook是怎么個玩法，馬上促使你把自己的MSN/Gtalk的朋友都拉過來玩，于是一個你熟識朋友的在線圈子很快就組成了。

現在很多的開心網用戶看到上面這一段，肯定覺得似曾相識，他們就是這樣開始用開心的，這里的互動關鍵點是什么呢？是作為一個網站，用戶為什么會來你的網站？

因為你的網站有大牛？還是因為你的網站有高質量的文章和討論？還是因為你的網站提供了很多吸引他的機會和資源？

如果用戶是因為這樣的理由來你的網站，那你抄襲Facebook就太失敗了。因為你的網站核心競爭力還是在于“內容”，還是要依靠UGC。那么一個封閉的社區、一個去中心化隔離用戶的社區要創造高質量的UGC就太難了。
Facebook靠的是你的朋友在上面活動，你可以參與他們的活動，這就是全部的理由。至于搞什么活動不重要，寫不寫什么文字也不重要，唯一重要的是你需要Facebook這樣一個tool來保持和你朋友之間的關系。

雖然Facebook不僅僅限于認識的朋友，但是其主要目的就是提供給熟識的朋友進行交流之用，因此Facebook本身并不提供任何全站的公共信息廣播，也不開放匿名訪問，你和自己認識的朋友之間的交流本來就是私密性的，這些信息本來就是被保護起來的。

而且尤其重要的一點就是Facebook并不鼓勵UGC（用戶創造內容），這是和其他web2.0網站的本質區別。Facebook真正鼓勵是你和你的朋友在Facebook上面“發生了互動的行為”，而不是“互動的所創造的內容”。

用這個標準你去衡量一下，就會發現開心網是唯一神似Facebook的網站，而其他網站，特別是UCenter Home簡直就是拙劣的Facebook模仿者，他完全沒有領會Facebook的本質，完全用自己做社區軟件的思路去套Facebook，搞出來的UCHome壓根就是一個社區網站，這一點大家看看5GSNS：

1、你為什么去5GSNS，因為你想看keso或者其他大牛寫的文章
2、你為什么去5GSNS，因為你知道keso或者其他大?，F在在干嗎
3、你為什么去5GSNS，因為上面有互聯網行業的招聘信息

說白了就是一句話：高質量的內容和資源在吸引你，所以要保持高質量的內容和資源，你必須依靠高質量的會員持續的UGC，那么我請問你，這和一個BBS有本質區別嗎？或者我這樣問你，keso不用UCHome，而是discuz!，會妨礙你訪問5GSNS嗎？會妨礙你泡在這個網站上面并且發貼嗎？所以小戴同學換湯不換藥呀。

四、Facebook怎么賺錢？

據說Facebook現在全球注冊會員有6000多萬了吧，網站流量也排名全球前10了，這樣的網站賺錢是不難的，難的是用簡單的商業模式持續的賺大錢。無論是Facebook在網站上面搞搞電子商務賣賣商品也好，搞搞網絡招聘賣賣人頭也好，搞搞游戲賣賣道具也好，都能賺錢，但是這些商業模式有問題：

1、無論是電子商務、網絡招聘、網絡游戲或者其他的什么商業模式，都是劃分具體的用戶群體去賺特定人群的錢，無形之中，潛在客戶就少了一大半，Facebook坐擁6000萬會員，商業模式的覆蓋面必須廣，去賺小眾的錢就是個失敗的商業模式。

2、進入特定的分眾領域，以Facebook這樣的通用SNS網站來說，競爭力根本不及專業的垂直網站，你做電子商務做不過ebay，做網絡招聘做不過monster，做網絡游戲做不過爆雪，都只能吃點殘羹冷炙。而且這種專業領域，你Facebook根本沒有積累，你需要花多么大的代價才能摸清楚這里面的水有多深呀。

3、你做這些垂直領域的生意，其實就是和Facebook平臺上面的開發商在搶生意，這是一個大忌，會破壞整個Facebook平臺的商業生態鏈條。而這個大忌，校內網正在不遺余力的去犯。

那Facebook怎么辦？靠廣告嗎？廣告是一條路，但光靠廣告不行。Facebook在2007年廣告收入是1.45億美元。這個收入水平和Yahoo這樣的門戶網站無法相提并論，也遠遠不足以盈利和上市。

其實在網絡廣告市場，已經被證明的廣告模式只有兩種：搜索引擎的關鍵字廣告和媒體網站的媒體廣告，也就是Google模式和Yahoo模式，或者說國內的百度模式和新浪模式。前者依靠拍賣廣告關鍵字賺錢，后者依靠網絡媒體內容平臺傳播影響力。

而Facebook的精準廣告投放只能依靠CPC（每點擊成本）來計費，而我們知道Google的adsense收入是非常可憐的，他的主要廣告收入來自競價排名。Facebook的非UGC特性決定了他是一個沒有內容的網站，無法像媒體網站那樣賣內容廣告，作為一個對比，開放式的SNS網站MySpace就不同了，他的網站互動產生了巨大的UGC，所以他的廣告收入是Facebook的3倍以上。因此光靠廣告收入，對于Facebook來說非常的不夠。

那么Facebook的錢途在哪里？

Facebook的真正錢途在于從app開發商身上賺錢！我們看看淘寶網是怎么賺錢的就知道了：淘寶網開店不收費，但是你想成為誠信商家，你想進駐淘寶商城，你想在淘寶的搜索上面靠前，你想獲得淘寶的高級服務，那么請乖乖交錢。而淘寶上面的大商家是很愿意掏這筆錢的，因為淘寶這個平臺可以讓他賺到更多的錢。

Facebook現在就是一門心思做平臺，不做應用，盡量能開放的數據全部開放出去，不遺余力的培養app開發商，為app開放商創造最好的賺錢途徑。Facebook就是一個巨大的網店，而app開發商就是上面免費租賃店面的商家，兜售自己的玩具，吸引用戶來玩。app開發商可以去做網絡招聘、app開發商可以去做機票預定、app開發商可以去做電子商務，現在Facebook上面已經有幾萬個app了，其中真正賺錢的app還不是特別豐富。等到Facebook平臺上面有100萬個賺錢的app商家的時候，Facebook再面向app商家推出增值服務，你可以想像一下到時候Facebook賺錢是多么容易的事情。

所以Facebook并不需要直接從注冊用戶身上賺錢，而是把面向用戶的細分垂直領域的賺錢機會統統留給app商家，同時也把這些細分領域的成本、風險和時間統統節省了，Facebook只要把自己的平臺做的足夠好，給app商家提供足夠好的免費服務和增值服務，就可以坐在家里收錢了，壓根不需要自己親自一個細分領域一個細分領域辛苦的開拓。從這一點來看，校內是多么的愚蠢和短視。為什么現在Facebook這么全心全意的伺候app開發商，當然是因為app開發商將來就是Facebook的衣食父母呀。

posted @ 2008-08-01 11:29 肖馬輝閱讀(211) | 評論 (1) | 編輯收藏

1億動態PV/天(超級數據庫緩沖解決方案)

說是支持1億pv/天，也許有點夸張，也是為了吸引您能點進來，如果您能認真看完相信也不會讓您失望，當然，肯定有很多“高手”會對此會嗤之以鼻，沒關系，有很多眼高手低的人總喜歡評論別人卻從不會看清自己。

如果大家真想支持我、支持中國人開源項目，請把該文貼到自己的博客中或者收藏本文，記得包含文檔的下載地址?。。。。。?！謝謝。

我說的系統主要是構建在hibernate之上的高效數據庫緩存系統，其中包含了分布式解決方案，該系統已經應用在舍得網上了，沒有發現大問題，本人也相信該系統已經足夠強大，應付數百萬IP/天的應用都不是問題，我這么說肯定有人會對此表示懷疑，其實系統到底能撐多少IP/天不在于系統本身而是在于使用該系統的人。

代碼看上去很簡單，其實卻是兩年經驗的總結，整過過程也遇到了很多難點，最后一一解決了，所以也請各位珍惜他人的勞動成果。本系統非常簡潔易用，主程序 BaseManager.java不到1000行代碼，用“精悍”來形容絕對不為過，1000行代碼卻包含了數據庫對象的緩存、列表和長度的緩存、按字段散列緩存、update延時更新、自動清除列表緩存等功能，用它來實現像論壇、博客、校友錄、交友社區等絕大部分應用網站都足夠了。

我在理想狀態下做了壓力測試，在沒有數據庫操作的jsp頁面(舍得網新首頁)里可以完成2000多requests每秒（正常情況可能有1/1000的 request有數據庫查詢，其余999/1000都是直接從緩存里讀?。?，物品詳情頁每秒可完成3000多requests，純靜態html頁面也只能完成7000多requests/秒，我對首頁進行了三個小時的壓力測試，完成了24850800個requests，java一點事都沒有，內存沒有上漲。按照2000個requests/秒算，一天按15小時計算，那么每天能完成3600*15*2000=1億零8百萬requests，當然這是理想狀態，實際狀態就算打一折，還能完成1000萬pv/天，要知道，這只是一個普通1萬3千塊錢買的服務器，內存4G，CPU2個，LinuxAS4系統， apache2.0.63/resin2.1.17/jdk6.0的環境。

現在進入正題。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

為什么要用緩存？如果問這個問題說明你還是新手，數據庫吞吐量畢竟有限，每秒讀寫5000次了不起了，如果不用緩存，假設一個頁面有100個數據庫操作， 50個用戶并發數據庫就歇菜，這樣最多能支撐的pv也就50*3600*15=270萬，而且數據庫服務器累得半死，搞不好什么時候就累死了。我的這套緩存系統比單獨用memcached做緩存還要強大，相當于在memcached上再做了兩級緩存，大家都知道memcached很強了，但是吞吐量還是有限，每秒20000次get和put當遇到超大規模的應用時還是會歇菜，本地HashMap每秒可執行上百萬次put和get，在這上面損耗的性能幾乎可以忽略不記了。溫馨提示：能不用分布式的時候就不要用分布式，非用分布式的時候再考慮用memcached，我的緩存系統在這方面都已經實現了，改個配置就可以了，有興趣的可以仔細測試測試！

一般數據庫緩存在我看來包含四種。第一種：單個對象的緩存（一個對象就是數據庫一行記錄），對于單個對象的緩存，用HashMap就可以了，稍微復雜一點用LRU算法包裝一個HashMap，再復雜一點的分布式用memcached即可，沒什么太難的；第二種：列表緩存，就像論壇里帖子的列表；第三種：長度的緩存，比如一個論壇板塊里有多少個帖子，這樣才方便實現分頁。第四種：復雜一點的group，sum，count查詢，比如一個論壇里按點擊數排名的最HOT的帖子列表。第一種比較好實現，后面三種比較困難，似乎沒有通用的解決辦法，我暫時以列表緩存（第二種）為例分析。

mysql和hibernate的底層在做通用的列表緩存時都是根據查詢條件把列表結果緩存起來，但是只要該表的記錄有任何變化（增加/刪除/修改），列表緩存要全部清除，這樣只要一個表的記錄經常變化（通常情況都會這樣），列表緩存幾乎失效，命中率太低了。

本人想了一個辦法改善了列表緩存，當表的記錄有改變時，遍歷所有列表緩存，只有那些被影響到的列表緩存才會被刪除，而不是直接清除所有列表緩存，比如在一個論壇版（id=1）里增加了一個帖子，那么只要清除id=1這個版對應的列表緩存就可以了，版id=2就不用清除了。這樣處理有個好處，可以緩存各種查詢條件（如等于、大于、不等于、小于）的列表緩存，但也有個潛在的性能問題，由于需要遍歷，CPU符合比較大，如果列表緩存最大長度設置成10000，兩個4核的CPU每秒也只能遍歷完300多次，這樣如果每秒有超過300個insert/update/delete，系統就吃不消了。

在前面兩種解決辦法都不完美的情況下，本人和同事經過幾個星期的思索，總算得出了根據表的某幾個字段做散列的緩存辦法，這種辦法無需大規模遍歷，所以 CPU符合非常小，由于這種列表緩存按照字段做了散列，所以命中率極高。思路如下：每個表有3個緩存Map（key=value鍵值對），第一個Map是對象緩存A，在A中，key是數據庫的id，Value是數據庫對象（也就是一行數據）；第二個Map是通用列表緩存B，B的最大長度一般1000左右，在B中，key是查詢條件拼出來的String（如start=0,length=15#active=0#state=0），Value是該條件查詢下的所有id組成的List；第三個Map是散列緩存C，在C中，key是散列的字段（如根據userId散列的話，其中某個key就是userId= 109這樣的String）組成的String，value是一個和B類似的HashMap。其中只有B這個Map是需要遍歷的，不知道說明白了沒有，看完小面這個例子應該就明白了，就用論壇的回復表作說明，假設回復表T中假設有字段id，topicId，postUserId等字段（topicId就是帖子的id，postUserId是發布者id）。

第一種情況，也是最常用的情況，就是獲取一個帖子對應的回復，sql語句應該是象
select id from T where topicId=2008 order by createTime desc limit 0,5
select id from T where topicId=2008 order by createTime desc limit 5,5
select id from T where topicId=2008 order by createTime desc limit 10,5
的樣子，那么這種列表很顯然用topicId做散列是最好的，把上面三個列表緩存（可以是N個）都散列到key是topicId=2008這一個Map 中，當id是2008的帖子有新的回復時，系統自動把key是topicId=2008的散列Map清除即可。由于這種散列不需要遍歷，因此可以設置成很大，例如100000，這樣10萬個帖子對應的所有回復列表都可以緩存起來，當有一個帖子有新的回復時，其余99999個帖子對應的回復列表都不會動，緩存的命中率極高。

第二種情況，就是后臺需要顯示最新的回復，sql語句應該是象
select id from T order by createTime desc limit 0,50
的樣子，這種情況不需要散列，因為后臺不可能有太多人訪問，常用列表也不會太多，所以直接放到通用列表緩存B中即可。

第三種情況，獲取一個用戶的回復，sql語句象
select id from T where userId=2046 order by createTime desc limit 0,15
select id from T where userId=2046 order by createTime desc limit 15,15
select id from T where userId=2046 order by createTime desc limit 30,15
的樣子，那么這種列表和第一種情況類似，用userId做散列即可。

第四種情況，獲取一個用戶對某個帖子的回復，sql語句象
select id from T where topicId=2008 and userId=2046 order by createTime desc limit 0,15
select id from T where topicId=2008 and userId=2046 order by createTime desc limit 15,15
的樣子，這種情況比較少見，一般以topicId=2008為準，也放到key是topicId=2008這個散列Map里即可。

總結：這種緩存思路可以存儲大規模的列表，緩存命中率極高，因此可以承受超大規模的應用，但是需要技術人員根據自身業務邏輯來配置需要做散列的字段，一般用一個表的索引鍵做散列（注意順序，最散的字段放前面），假設以userId為例，可以存儲N個用戶的M種列表，如果某個用戶的相關數據發生變化，其余N -1個用戶的列表緩存紋絲不動。以上說明的都是如何緩存列表，緩存長度和緩存列表思路完全一樣，如緩存象select count(*) from T where topicId=2008這樣的長度，也是放到topicId=2008這個散列Map中。如果再配合好使用mysql的內存表和memcached，加上F5設備做分布式負載均衡，該系統對付像1000萬IP/天這種規模級的應用都足夠了，除搜索引擎外一般的應用網站到不了這種規模。

再次申明：系統到底是不是強大不在系統本身而在于使用該系統的人?。。?/strong>

這個緩存系統是我和同事幾年經驗的總結，看似簡單，其實也沒那么簡單，把它作為開源有下面幾個目的：第一，真的希望有很多人能用它；第二：希望更多的人能夠完善和改進它；第三：希望大家能聚到一起為通用高效數據庫緩存構架作出貢獻，畢竟，數據庫操作是各種應用最常用的操作，也是最容易產生性能瓶頸的地方。

Zip包中包含了配置方法和測試用的jsp，只要把它配置成一個web應用就可以快速調試并看到緩存的力量了，文檔和下載地址是http://shedewang.com/akaladocs/api/com/akala/dbcache/core/BaseManager.html。群組的地址是http://groups.csdn.net/shedewang_db_cache

配置說明文件在docs/開始配置.txt里有說明。

最后啰嗦一句，如果大家真想支持我、支持中國人開源項目，請把該文貼到自己的博客中或者收藏本文，記得包含文檔的下載地址?。。。。。?！謝謝。thank you and Good luck。

posted @ 2008-07-28 10:16 肖馬輝閱讀(297) | 評論 (0) | 編輯收藏

SQL語句

select * from bookReview a where rid=(select top 1 rid from bookReview where isbn=a.isbn order by commendtimes desc,rid desc)

posted @ 2008-07-25 14:30 肖馬輝閱讀(119) | 評論 (0) | 編輯收藏

分析死鎖并處理

--死鎖 /****************************************************************************************************************************************************** 死鎖指兩個以上事務相互阻塞相互等待對方釋放它們的鎖，SQL Server會通過回滾其中一個事務並返回一個錯誤來自已解決阻塞問題，讓其他事務完成它們的工作。整理人：中國風(Roy) 日期:2008.07.20 ******************************************************************************************************************************************************/ set nocount on ; if object_id('T1') is not null drop table T1 go create table T1(ID int primary key,Col1 int,Col2 nvarchar(20)) insert T1 select 1,101,'A' insert T1 select 2,102,'B' insert T1 select 3,103,'C' go if object_id('T2') is not null drop table T2 go create table T2(ID int primary key,Col1 int,Col2 nvarchar(20)) insert T2 select 1,201,'X' insert T2 select 2,202,'Y' insert T2 select 3,203,'Z' go 生成表數據: /* T1: ID Col1 Col2 ----------- ----------- -------------------- 1 101 A 2 101 B 3 101 C T2: ID Col1 Col2 ----------- ----------- -------------------- 1 201 X 2 201 Y 3 201 Z */ 防止死鎖： 1、最少化阻塞。阻塞越少，發生死鎖機會越少 2、在事務中按順序訪問表（以上例子：死鎖2） 3、在錯誤處理程式中檢查錯誤1205並在錯誤發生時重新提交事務 4、在錯誤處理程式中加一個過程將錯誤的詳細寫入日誌 5、索引的合理使用(以上例子：死鎖1、死鎖3) 當發生死鎖時，事務自動提交，可通過日誌來監視死鎖死鎖1(索引): --連接窗口1 --1步: begin tran update t1 set col2=col2+'A' where col1=101 --3步: select * from t2 where col1=201 commit tran --連接窗口2 --2步: begin tran update t2 set col2=col2+'B' where col1=203 --4步: select * from t1 where col1=103 commit tran --連接窗口1:收到死鎖錯誤,連接窗口2得到結果: /* 訊息 1205，層級 13，狀態 51，行 3 交易 (處理序識別碼 53) 在鎖定資源上被另一個處理序鎖死並已被選擇作為死結的犧牲者。請重新執行該交易。 */ --連接窗口2:得到結果 /* ----------- ----------- -------------------- 3 103 C */ 處理方法: --在t1、t2表的col1條件列建索引 create index IX_t1_col1 on t1(col1) create index IX_t2_col1 on t2(col1) go --連接窗口1 --1步: begin tran update t1 set col2=col2+'A' where col1=101 --3步: select * from t2 with(index=IX_t2_col1)where col1=201 --因表數據少，只能指定索引提示才能確保SQL Server使用索引 commit tran --連接窗口2 --2步: begin tran update t2 set col2=col2+'B' where col1=203 --4步: select * from t1 with(index=IX_t1_col1) where col1=103 --因表數據少，只能指定索引提示才能確保SQL Server使用索引 commit tran --連接窗口1: /* ID Col1 Col2 ----------- ----------- -------------------- 1 201 X (1 個資料列受到影響) */ --連接窗口2 /* ID Col1 Col2 ----------- ----------- -------------------- 3 103 C (1 個資料列受到影響) */ 死鎖2(訪問表順序): --連接窗口1: --1步: begin tran update t1 set col1=col1+1 where ID=1 --3步: select col1 from t2 where ID=1 commit tran --連接窗口2: --2步: begin tran update t2 set col1=col1+1 where ID=1 --4步 select col1 from t1 where ID=1 commit tran --連接窗口1: /* col1 ----------- 201 (1 個資料列受到影響) */ --連接窗口2: /* col1 ----------- 訊息 1205，層級 13，狀態 51，行 1 交易 (處理序識別碼 54) 在鎖定資源上被另一個處理序鎖死並已被選擇作為死結的犧牲者。請重新執行該交易。 */ 處理方法: --改變訪問表的順序 --連接窗口1: --1步: begin tran update t1 set col1=col1+1 where ID=1 --3步: select col1 from t2 where ID=1 commit tran --連接窗口2: --2步: begin tran select col1 from t1 where ID=1--會等待連接窗口1提交 --4步 update t2 set col1=col1+1 where ID=1 commit tran 死鎖3(單表): --連接窗口1: while 1=1 update T1 set col1=203-col1 where ID=2 --連接窗口2: declare @i nvarchar(20) while 1=1 set @i=(select col2 from T1 with(index=IX_t1_col1)where Col1=102);--因表數據少，只能指定索引提示才能確保SQL Server使用索引 --連接窗口1 /* 訊息 1205，層級 13，狀態 51，行 4 交易 (處理序識別碼 53) 在鎖定資源上被另一個處理序鎖死並已被選擇作為死結的犧牲者。請重新執行該交易。 */ 處理方法: 1、刪除col1上的非聚集索引,這樣影響SELECT速度，不可取. drop index IX_t1_col1 on t1 2、建一個覆蓋索引 A、drop index IX_t1_col1 on t1 B、create index IX_t1_col1_col2 on t1(col1,col2) 通過SQL Server Profiler查死鎖信息: 啟動SQL Server Profiler——連接實例——事件選取範圍——顯示所有事件選擇項: TSQL——SQL:StmtStarting Locks——Deadlock graph(這是SQL2005新增事件，生成包含死鎖信息的xml值) ——Lock:DeadlockChain 死鎖鏈中的進程產生該事件，可標識死鎖進程的ID並跟蹤操作 ——Lock:Deadlock 該事件發生了死鎖

阻塞分析：
http://blog.csdn.net/roy_88/archive/2008/07/21/2682044.aspx

posted @ 2008-07-22 12:59 肖馬輝閱讀(200) | 評論 (0) | 編輯收藏

最近的一些隨感——簡歷(轉)

本文來自:http://www.cnblogs.com/sumtec/archive/2008/06/26/1223460.html
博客園技術帖子太多了，這是我真實的感受。也許是因為博客園定位于技術博客，所以會把其他內容劃分到別的區里面，這一直是我覺得最不爽的地方。因為這樣，有可能很多優秀的文章就被埋沒了。其實完全可以都集中在首頁顯示，不好的刷下來，好的頂上去。以前說是沒有人管，那也確實是有心無力?，F在有點人力資源了，我覺得還是希望趕緊考慮一下這方面的事情。我寫這個隨筆的時候，就猶豫，該不該發在首頁？最后還是覺得發吧，我覺得我想和大家交流的這些內容，估計還是會對一部分人產生一定幫助的。其實，我還想聽聽dudu的創業經驗談。

好，牢騷發完了，回到正題。

今天一晚上連著看了十幾個簡歷，看得我頭都大了。什么？不就是看看簡歷么，有什么好頭痛的？沒錯，以前我也這么想的，可最近公司做了一個有關招聘的培訓，才知道面試之前、之中、之后的工作事項有這么多。于是，最近的面試就要好好做功課準備準備了?？僧斘艺婵催@么多簡歷的時候，就有點麻木了。不是么？平時已經夠忙的了，各種大小事務紛涌而至，而且我所在部門還是“重要且緊急”甚至“不重要但緊急”事項的窗口?？上攵斈憧匆欢训暮啔v的時候，就多么的期望你面前的簡歷最好能夠回答你一切想要知道的問題。可是偏偏最頭痛的是，大部分的簡歷給我帶來的問題，比我想要知道的答案還要多。

舉例說明之前，先說說我從培訓中得到的知識吧：
一個公司，尤其是靠腦力掙錢的公司，其人力相關成本是極高的。這里面，自然也包含了招聘和解雇的成本。不要以為招聘成本就是一個HR員工的成本，還應該包括：
1、因為面試，需要占用的人力資源成本；
2、因為試用失敗，所支付的資金成本和時間成本；
3、因為最終雇傭了錯誤的人，所造成的資金損失，人力資源損失等。

具體數字我還真忘了，但是可以肯定的是，最終找到的合適員工，和你面試過的候選人之比，是非常小的，所以說招聘成本高。這還不包含招聘后，該員工所占用空間所需要花費的資金成本，該員工造成規模擴大之后的管理成本等。由此可見，招聘是一件多么重要的事情。比如說，找到一個合適的人，可以完成十個不合適的員工才能完成的工作量，前者的人力成本比后者的要明顯低很多。那么為什么我們不多花一點經歷，來認真對待招聘的事情呢？據我所知，很多公司的招聘工作，可能主要是HR那邊出力，然后具體相關部門的主管進行面試。實際上這是有很大問題的，應該是相關部門主管要在面試前做很多的功課，具體做什么這里不多說了，只說一個：你打算問候選人什么問題？

問題有哪些呢？這個我也不多列，至少得有下面這幾個吧（不限于此）：
1、簡歷中有什么疑點？例如工作經歷斷檔等；
2、過去的工作中，面對了什么問題，如何處理（而不是假大空的問：如果你是經理，你能面對壓力嗎？回答：能！@_@）

其中，我發現最有趣的一個問題是，很多人的簡歷中普遍存在一個（套）疑點：你回報的上級是什么人，職責是什么，你管理多少人，職責是什么，在你所在的工作中具體做什么事情？
很多人的簡歷都是這么列的：
2007.1-2008.1   北京XXX公司
職位：程序員
工作內容：用ABC.NET、OrnDB技術以及JUNK語言，構建了一個BC結構的XXX項目，該項目采用了0.5層的技術，實現了XXX、YYY、ZZZ的功能。全程參與了該項目的開發。

那么，我上面的疑點，一個都沒有解決。還有一個更嚴重的問題，是使用大量爛掉的關鍵字，例如：熟悉、精通、理解——當我面對這些詞的時候，幾乎已經看到發膩，甚至都搞不清楚到底是熟悉比精通厲害呢，還是理解才是萬歲。最糟糕的莫過于列出了一大堆的熟悉精通理解，我看到這樣的情況，就想不明白，到底哪個才是你最強的方面，哪一個是你最弱的方面，基本上說了等于沒說一樣。

好，反過來說，如果你是求職者，如何從幾百上千份的簡歷中脫穎而出呢？除了不要犯上述的常識性錯誤，還要注意突出你的不同之處。如何突出呢？要看你的工作經驗如何了。

如果你是剛畢業的毛頭小子

記住，不要列出一大堆的在校工作項目，尤其不要列你的畢設。中國大學的畢設水平有多爛，大家心知肚明，你又何苦把它統統列出來讓人鄙視一番呢？很不幸我當年就犯了這個錯誤。雖說現在想起來，我的畢設水平仍然有資格說是比普通的學生好上那么一點點，可是如果和真正的、成功的商業系統比起來，那都是小菜一碟。你向往的某個公司真的會覺得你做過的文件拷貝程序感興趣嗎？那只是一個程序，不是系統，因此人家不會覺得你做過什么。很不幸，我以前曾經也做過類似的事情。不過，我并不是說不列，列出一條你認為最自豪的就可以了。雖然比不上商業系統，但這足以證明你是一個積極的人，真正做過一點事情的人，不是那種渾渾噩噩過一生的人。其他的項目，一筆帶過就行了，寫多了簡直是浪費你的精力和版面，也浪費面試官的時間和感情。

除此之外，你還可以提供程序的源代碼（全部或部分），這是展示你的程序風格的一個很好的方式。不過建議你在給出這樣的代碼之前，仔細地考慮一下，你是否應該規整規整，重構重構？對于一個企業，要決定是否聘用一個員工，是一件很嚴肅的事情，因此真正面試之前，理應進行相應的準備工作。那么當你去準備面試的時候，也更應該如此了。我收到過一個源代碼，里面寫了一些.NET其實已經提供的功能，除此之外也出現了一些很長的方法，還有一些遺留的、被注釋掉的代碼，寫著這個沒有做出來。這樣的代碼其實在向你的主顧宣示著：其實我很糟糕，看，我的代碼就是這么糟糕，甚至于我來面試了，我也不樂于稍微修飾一下。您覺得這樣能獲得你想要的工作嗎？如果是你不在乎的工作，那另當別論，可你都不在乎這樣的工作，為什么要投這份簡歷呢？

你應該重點展示什么呢？相對于有經驗的人來講，缺乏經驗是你的缺點，同時也是你的優點。在雇主看來，你就是一張白紙，未來在這張白紙上可能會畫出一幅很棒的畫?？刹⒉皇敲恳粡埌准埗加型瑯拥慕Y果，原因在于紙張的質量。上好的紙張應該是好的東西點撥一下，就能自然展開，而糟糕的東西不會被畫上去。糟糕的紙張則相反，美好的東西畫了半天沒反應，糟糕的東西不知道怎么自動就有了。這個比喻還不太直接，直白的說，雇主期望你是這樣的一個人：
1、你很勤奮并且你很好學
2、你很好學并且一學就會
3、你學會了不止，還學得很精
4、學得很精了不止，還態度好

一個不勤奮的不好學的人，如何展望未來能給公司帶來價值呢？一個好的公司，會有一些培訓，縱然沒有，也會要求你自學。如果你學了半天都不會，你是勤奮好學那也沒有用。這個一學就會，其實是平日長時間進行自學鍛煉的結果，我也沒有一個“銀彈”供你解決這個問題。接下來，你不僅僅要學會了，還要精。所謂的精，就是你能說出道道來，能說出個所以然來。我非常頭痛的一點是，每次我面試都會問“interface”你是怎么理解的，其結果十有八九就是大眼瞪小眼?？墒沁@些人的簡歷上，會寫著自己會X、Y、Z還會三層結構，那interface是干嘛使的、為什么存在怎么會說不出來呢？每天花點時間，先把這些最基本的思想弄清楚了，你才可能找到一份好工作。也許會花你幾個月的時間，不過如果不花時間做這樣的事情，你花多少時間也找不到一份你覺得滿意的工作的。最后一點其實是很重要，有句話：態度決定行為，行為決定習慣，習慣決定性格，性格決定命運。如果你整天懶懶散散，上面交待你做的事情不到最后一天不做，又或者沒有明確的利益你就不做事情，這樣的態度肯定會決定你沒有什么好命運的（含著金鑰匙的除外，這種人不需要找工作）。

上面這些是剛畢業的學生的寫簡歷時的一些基本思路。

如果你是工作幾年，有了一定經驗，甚至是豐富經驗的人

那么很顯然，你的優勢在于經驗。這個經驗不在于你坐過了什么項目，而是你用什么知識、工具做了個多大規模的事情，其間遇到些什么樣的困難，最后如何克服了。很多的簡歷里面，都只是說作了一個什么項目。至于說這個項目有多復雜，你負責其中的什么內容，你在其間使用了什么知識和工具，遇到什么困難，統統不說。這樣的結果就是我看完了還是等于什么都不知道，就算你說我05-08年期間參與的項目有Windows Server 2008，Visual Studio 2008，那又怎么樣呢？我心里面也許會覺得，可能其實你只不過作了其中里面一個很小很小的部分，比如寫了一個計算器，或者 OpenFileDialog。這樣對于你是不利的，因為如果另一個和你競爭的候選人，把他的經歷寫得比較具體，那也許就會約見他而不約見你。

當我看過這么多的簡歷之后，我就覺得，如果我再找工作的時候，我就會用PPT把我這幾年做的工作列出來，把我參與過的最大的一個系統的拓撲圖畫出來，把我遇到過并解決過的問題舉一個出來，把我參加過的某個重要培訓以及心得列出來。這樣的PPT，至少讓人能看得津津有味，直到我參與過什么樣的事情，也能證明我能勝任我想要爭取的崗位。說到這里，我也想提一下，我認為，文字太多其實不是好事，所以簡歷文字要精煉在精煉。詳細列出10個項目，你說有多少人能耐著性子看完？幾乎沒有。詳細列出1個項目呢？我覺得大部分人應該還是愿意看的。所以你覺得用同樣多的文字，粗略列出10個項目好呢，還是詳細介紹1個？我建議剩余的可以一筆帶過，附帶說明如果面試時有興趣了解，可以詳細說明。同時，圖片比文字的說明力強多了，為什么不多擺幾個圖片呢？一個拓撲圖，基本上就能把你的項目復雜度給說清楚了，用文字可得要寫好大一段，是否能看得明白還不一定。圖基本上瞄一眼就明白，文字可得要反復琢磨，對于面試官來講前者絕對是賞心悅目，后者絕對是折磨人。

與剛出道的人比起來，你的劣勢在于經驗。經驗多了難免容易坐享其成，不愿意接受新東西，或者有自覺牛X的感覺。
先說前者。我遇到過工作多年的候選人，面試時問3.5的東西例如linq、WCF等一問三不知，倒是不停的說很古董的解決方案。不懂就算了，有的東西還強裝了解，說出來的不對。其實不知道就不知道好了，多數企業需要的是踏實的人，不希望你掩蓋真相。俗話說有問題不可怕，有問題不知道不解決才可怕。也許你也是對很多最新的知識不了解，畢竟工作經驗多的人，可能會負責比較多的事情。公司也可能不愿意冒風險使用新技術，平時也沒有時間學習，怎么辦？其實解決的辦法很簡單：開始投簡歷之前，趕緊先多學習一些新的東西。寧愿少工作一兩個月，也要先把這些工作做好，磨刀不誤砍柴工嘛。再說了，也算給自己放個假。當然了，如果工作中有機會，或者能夠爭取機會，那是再好不過的。
再說后者。平時自己給自己打氣，沒人的時候，或者對著老婆的時候，你可以自覺牛X一下，但是寫簡歷的時候千萬不要。先不說面試官是否比你厲害，這樣的感覺面試官至少會判斷你態度有問題。其次，你要真那么牛X，為什么還要去面試呢？獵頭早該找上門來啦，準東家早就對你求賢若渴啦，三顧茅廬啦。嗯，有人會覺得，牛X怎么可能寫簡歷里面呢？我舉一個例子，我就看到一些簡歷，會羅列很多會的東西。其實完全沒有必要，首先，這么十幾個技術知識里面，總有強弱之分，列出強的那么兩三個就夠了。再牛X，面試官也沒有時間問你超過5個以上的技術知識，所以你也沒必要列超過5個。其次，這就是一種想告訴別人“我其實是很牛 X的”。如果萬一別人問到的，就是你列出的那十幾個技術中最弱的那一個，而恰好面試官最強的就是這項，后果可想而知。

工作經歷比較多的人當中，還有一部分的是有創業經歷的，我也可以分享一下。對于這種候選人，面試官最擔心的恐怕是“你的心很野”的問題。因此，如果你能夠把你的人生規劃說清楚，也許更能打動面試官。此外，由創業經驗的人，一定不是平常人。不是平常人有兩種：一種是非常優秀，只是暫時失?。贿€有一種，就是想法偏執，其實運氣再好，也就那樣。前者后者該如何寫簡歷，我沒有什么可以分享的，因為我還沒有仔細想過。但有一點，無論前者后者，都是很重要的：就是要承認你的失敗，同時還要總結原因。理由是，不承認失敗的人，感覺不太踏實，或者不太現實；而沒有總結的人，有可能就是總結能力欠缺，或者從來不做總結。當然，其實這些問題有沒有創業經歷的候選人，都有這種“維度”——即需要衡量的方面。但是有創業經歷在簡歷上，無疑就在提醒面試官這方面的問題。你不解答這些問題，如果面試官忘了問，那么這個困惑就會存在，你就很可能會被刷下來。我已有的案例中，就有一個我覺得個方面都不錯的，結果上司擔心他干一段時間還會再次創業，于是沒有考慮。

最后，當你面試的時候，一定要想辦法弄清楚面試官的困惑點，要解答這些困惑點，才能得到你想要的工作。當然了，我上面說的那些，都是假設你已經比較有料的情況。如果你自覺能力不足，簡歷再好，面試能力再強，也是不能解救的，試用期必定暴露問題。因此，能力不足的，首先補能力，這篇文章恐怕對你幫助不大。

posted @ 2008-07-21 16:58 肖馬輝閱讀(123) | 評論 (0) | 編輯收藏

SQL中遞歸.使用變量表.

DECLARE @t TABLE(ID char(3),PID char(3),Name nvarchar(10))
INSERT @t SELECT '001',NULL ,'山東省'
UNION ALL SELECT '002','001','煙臺市'
UNION ALL SELECT '004','002','招遠市'
UNION ALL SELECT '003','001','青島市'
UNION ALL SELECT '005',NULL ,'四會市'
UNION ALL SELECT '006','005','清遠市'
UNION ALL SELECT '007','006','小分市'

--深度排序顯示處理
--生成每個節點的編碼累計(相同當單編號法的編碼)
DECLARE @t_Level TABLE(ID char(3),Level int,Sort varchar(8000))
DECLARE @Level int
SET @Level=0
INSERT @t_Level SELECT ID,@Level,ID
FROM @t
WHERE PID IS NULL
WHILE @@ROWCOUNT>0
BEGIN
    SET @Level=@Level+1
    INSERT @t_Level SELECT a.ID,@Level,b.Sort+a.ID
    FROM @t a,@t_Level b
    WHERE a.PID=b.ID
        AND b.Level=@Level-1
END

--顯示結果
SELECT SPACE(b.Level*2)+'|--'+a.Name
FROM @t a,@t_Level b
WHERE a.ID=b.ID
ORDER BY b.Sort

posted @ 2008-07-10 09:42 肖馬輝閱讀(325) | 評論 (0) | 編輯收藏

vb檢驗EMAIL郵件地址(正則表達式)

Dim MyReg As RegExp
Private Sub Form_Activate()
Text1.SetFocus
End Sub

Private Sub Form_Load()
Set MyReg = New RegExp
MyReg.IgnoreCase = True
MyReg.Pattern = "^[\w-\.]+@\w+\.\w+$"
End Sub

Private Sub Text1_LostFocus()
If Not MyReg.Test(Text1) Then
MsgBox "無效的輸入"
Text1.SetFocus
End If
End Sub
其中Pattern定義了輸入的有效性規則，表示在@之前允許輸入字母、下劃線、數字及連接符，在小數點前后只能輸入字母、數字及下劃線。

posted @ 2008-07-07 17:41 肖馬輝閱讀(660) | 評論 (0) | 編輯收藏

僅列出標題
共7頁: 上一頁 1 2 3 4 5 6 7 下一頁

導航

統計

常用鏈接

留言簿(3)

隨筆檔案

搜索

最新評論

閱讀排行榜

評論排行榜