1、z-blog博客如何優化？
第一：首頁的標題，在zblog後台設置網站的標題，建議網站的子標題可以不用寫（我反正是沒有寫）；我這樣設置在標題的最後會多戶一個小橫杠「-」，這是因為我的網站子標題沒有寫，如果寫了網站子標題，那麼在小橫杠後面就會顯示寫的內容，所以就要找到default.html（這個在模板文件夾裡面的TEMPLATE裡面），找到title代碼只保留<#ZC_BLOG_TITLE#> 這個，其他都刪掉，這樣你的博客標題就是你設置的標題了，不會多出小橫杠了。
第二：文章的標題title位置，在默認情況下，在文章頁面title顯示的是博客名稱+文章標題的名稱，做seo都知道，這樣不利於搜索引擎抓取，那麼該如何修改，方法很簡單，還是在模板文件裡面找到single.html，同樣找到title這行代碼修改成：<title><#BlogTitle#><#ZC_MSG044#><#ZC_BLOG_TITLE#></title>，這樣文章頁面就會變成文章標題+博客名稱了。在修改之前的文章頁面這樣做改變不了，需要找到原來頁面的文件，直接在那裡修改就可以。標簽也是這樣設置
第三個：博客的Meta（這個我感覺可加可不加，看自己喜好吧）默認模板裡面是沒有 keywords，description，針對單個文章頁面，就修改single.html，加入下面兩行代碼每篇文章都會有了
2、怎麼解決wordpress分頁title標題重復不利於SEO的問題
如果是分頁，內容比較長，那隻能是重復也沒有辦法，或者是你把內容寫在一個頁面上。
3、請教高手：oracle臨時表創建優化
http://www.upschool.com.cn/e/1836/2007/16/10264717_1.shtml
關於Oracle臨時表數據cache的研究
Global Temporary Table是Oracle 8i中出現的特性，可以用於存儲事務或會話中的臨時數據。它的出現大大方便了開發人員。但是在使用上面，由於它本身的特性，一直存在一些問題。
簡單說一下臨時表，它的數據只對調用它的會話可見，一個會話是無法訪問其他會話中的臨時表的數據。可以在創建時指定它是事務級的還是會話級的。它被創建在用戶的默認臨時表空間上，在創建時不會分配段，而是在會話中第一次insert的時候從零時表空間分配數據段。DML時，不會產生redo log，但是會產生undo log。並且無法生成臨時表或者臨時表上索引的統計信息（勢必會影響CBO下的查詢計劃）。
下面研究一下臨時表的數據是如何存儲，又是如何獲得的，如何cache在內存中的：
我們知道，對於普通表(regular tables)，第一對表進行掃描時，會將掃描到的數據放到buffer cache中，以便以後如果有其他事務需要掃描相同數據時，直接從內存中讀，而不產生disk read。並且，同時在LUR和MUR鏈中記錄一個點，以決定這些數據什麼時候被page out。
那對於臨時表呢？以前我是這樣認為的，既然臨時表的數據只對會話可見，那它的數據就不應該放在公用的buffer cache中，而放在每個會話的PGA裡面更合適。那這個觀點正確嗎？我查了很多資料，並沒有明確的指出臨時表的數據應該是cache在內存的哪一塊。由於這些都是Oracle internal的東東，沒有任何公布的資料可查，我們下面來做一些試驗來看看Oracle到底怎麼管理臨時表的數據的。
臨時表中的數據到底cache在哪裡？
首先，創建測試用的對象：
創建一張普通表：
CREATE TABLE pga_ttt (
A VARCHAR2(100)
);
給表插入測試數據：
INSERT INTO pga_ttt values(1);
創建臨時表：
CREATE GLOBAL TEMPORARY TABLE PGA_TEST
(
A VARCHAR2(3000),
B VARCHAR2(2000),
C VARCHAR2(2000)
)
ON COMMIT PRESERVE ROWS;
測試過程：
1. 修改db cache size為一個較小的值：
ALTER SYSTEM SET DB_CACHE_SIZE = 50M;
2. 重起資料庫：
STARTUP FORCE
這時的資料庫的內存中應該是比較干凈的。
3. 先看一下一些什麼對象已經cache在buffer cache中了：
SELECT DISTINCT objd FROM v$bh ORDER BY objd;
OBJD
----
2
3
6
7
8
... ...
4294967294
4294967295
這些對象應該都是系統啟動時載入的一些系統對象。
4. 另外啟動兩個會話，分別執行以下語句：
INSERT INTO PGA_TEST VALUES(1, 1, 1);
SELECT * FROM PGA_TEST;
5. 再看下buffer cache中的對象：
SELECT DISTINCT objd FROM v$bh ORDER BY objd;
OBJD
----
2
3
6
7
... ...
6693385
6693513
4294967294
4294967295
這時，可以發現多出兩個對象來了。但不能確定和pga_test有什麼關系，也許又是兩個系統對象。
6. 查一下pga_test的object number
SELECT object_id FROM dba_objects WHERE object_name = 'PGA_TEST';
53513
比較失望L，這個object number和剛才那兩個新cache到buffer cache中的object number並不相同。但是這還並不能說明臨時表的數據一定沒有cache到buffer cache中去。
接下來繼續測試，將buffer cache mp出來！
7. Dump出buffer cache
用level 3將整個buffer cache都mp出來，這將會產生一個比較大的trace文件（折就是為什麼要把buffer cache設小一些的原因）
oradebug setmypid
oradebug mp buffers 3
8. 打開trace文件
在trace文件中，找到一下兩段：
· 第一段：
BH (183EBEEC) file#: 201 rdba: 0x0066220a (1/2499082) class: 1 ba: 18114000
set: 3 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 574
dbwrid: 0 obj: 6693385 objn: 53513 tsn: 3 afn: 201
hash: [201d7a88,201d7a88] lru: [183ebff0,183ebe90]
ckptq: [NULL] fileq: [NULL] objq: [1ea81d98,183ec044]
st: XCURRENT md: NULL tch: 2
flags: buffer_dirty temp_data gotten_in_current_mode redo_since_read
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
buffer tsn: 3 rdba: 0x0066220a (1/2499082)
scn: 0x0000.00550a09 seq: 0x00 flg: 0x08 tail: 0x0a090600
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex mp of block: st=0, typ_found=1
Dump of memory from 0x18114000 to 0x18116000
18114000 0000A206 0066220A 00550A09 08000000 [....."f...U.....]
... ...
... ...
... ...
18115830 20202020 20202020 20202020 20202020 [ ]
Repeat 123 times
18115FF0 20202020 20202020 20202020 0A090600 [ ....]
Block header mp: 0x0066220a
Object id on Block? Y
seg/obj: 0x662209 csc: 0x00.00 itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0006.01b.00000c9d 0x0080142b.088a.20 ---- 1 fsc 0x0000.00000000
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
data_block_mp,data header at 0x1811405c
===============
tsiz: 0x1fa0
hsiz: 0x14
pbl: 0x1811405c
bdba: 0x0066220a
76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x824
avsp=0x810
tosp=0x810
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0x824
block_row_mp:
tab 0, row 0, @0x824
tl: 6012 fb: --H-FL-- lb: 0x1 cc: 3
col 0: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
... ...
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
col 1: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
... ...
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
col 2: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
... ...
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
end_of_block_mp
· 第二段：
BH (183EC04C) file#: 201 rdba: 0x0066228a (1/2499210) class: 1 ba: 18118000
set: 3 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 574
dbwrid: 0 obj: 6693513 objn: 53513 tsn: 3 afn: 201
hash: [201e8d88,183e6a5c] lru: [183ec150,183ebff0]
ckptq: [NULL] fileq: [NULL] objq: [1ea81dd0,183ec1a4]
st: XCURRENT md: NULL tch: 2
flags: buffer_dirty temp_data gotten_in_current_mode redo_since_read
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
buffer tsn: 3 rdba: 0x0066228a (1/2499210)
scn: 0x0000.00550a08 seq: 0x00 flg: 0x08 tail: 0x0a080600
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex mp of block: st=0, typ_found=1
Dump of memory from 0x18118000 to 0x1811A000
18118000 0000A206 0066228A 00550A08 08000000 [....."f...U.....]
... ...
... ...
... ...
18119830 20202020 20202020 20202020 20202020 [ ]
Repeat 123 times
18119FF0 20202020 20202020 20202020 0A080600 [ ....]
Block header mp: 0x0066228a
Object id on Block? Y
seg/obj: 0x662289 csc: 0x00.00 itc: 2 flg: O typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0005.014.00000c58 0x008044a3.060a.08 ---- 1 fsc 0x0000.00000000
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
data_block_mp,data header at 0x1811805c
===============
tsiz: 0x1fa0
hsiz: 0x14
pbl: 0x1811805c
bdba: 0x0066228a
76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x824
avsp=0x810
tosp=0x810
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0x824
block_row_mp:
tab 0, row 0, @0x824
tl: 6012 fb: --H-FL-- lb: 0x1 cc: 3
col 0: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
... ...
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
col 1: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
... ...
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
col 2: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
... ...
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
end_of_block_mp
這兩段都是cache在buffer cache中的數據段。注意他們的基礎系統中的以下內容：
obj: 6693385 objn: 53513
obj: 6693513 objn: 53513
object number是53513，這正是pga_test的object number，對比一下後面數據塊的內容：
col 0: [2000]
31 20 20 20 ...（即』1 』）
col 1: [2000]
31 20 20 20 ...（即』1 』）
col 2: [2000]
31 20 20 20 ...（即』1 』）
正是從pga_test中的掃描到的數據。
再看objn前面的數字，是不是很眼熟？對了，這就是從v$bh中查到的在掃描臨時表後buffer cache中多出兩個對象的object number！這因該是為了保持各自會話的數據的獨立，Oracle創建了一個系統臨時對象（叢v$bh中看，這個臨時對象時屬於sys用戶的，不屬於當前用戶的），保持了與臨時表相同的結構，然後在buffer中開辟了一片區域，以系統臨時對象的名義存放各自數據，使之相互不影響。同時我們還可以留意到它們的LRU值是不同的。
另外看下他們的flags:
flags: buffer_dirty temp_data gotten_in_current_mode redo_since_read
buffer_dirty:因為臨時表需要先插入數據，所以被置了dirty標志；
temp_data:臨時表在第一次INSERT時，才在臨時表空間上分配臨時段，所以是屬於臨時數據；
gotten_in_current_mode:顯然，當前會話這在獲取各自臨時表中的數據，因此是當前被獲取模式下；
redo_since_read:這個不是十分明白。因為臨時表的DML是不會產生redo log的，會產生undo log，同時會產生針對這些undo的redo log（而不是臨時表的）。
現在，我們基本上可以得出這樣的推論：
推論1：臨時表的數據是cache在buffer cache中的。並且，為了保持各自會話的數據獨立，在buffer cache中為各個會話開辟一片區域來cache它們各自的數據。
以上推論可以和普通表來做一個對比。
在兩個會話中分別查詢普通表：
SELECT * FROM pga_ttt;
Dump 出cache buffer：
oradebug setmypid
oradebug mp buffers 3
查詢普通表的object number
SELECT object_id FROM dba_objects WHERE object_name = 'PGA_TTT';
53514
看看trace文件中的內容：雖然我們在兩個會話中都掃描了這張表，但是buffer cache只有一段它的數據段：
BH (18BE658C) file#: 5 rdba: 0x014097be (5/38846) class: 1 ba: 18810000
set: 3 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 64
dbwrid: 0 obj: 53514 objn: 53514 tsn: 5 afn: 5
hash: [202153d8,202153d8] lru: [18be6690,18be6530]
ckptq: [NULL] fileq: [NULL] objq: [18be6584,18be66e4]
st: XCURRENT md: NULL tch: 2
flags: only_sequential_access
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
buffer tsn: 5 rdba: 0x014097be (5/38846)
scn: 0x0000.005513e7 seq: 0x01 flg: 0x06 tail: 0x13e70601
frmt: 0x02 chkval: 0xa15f type: 0x06=trans data
Hex mp of block: st=0, typ_found=1
Dump of memory from 0x18810000 to 0x18812000
18810000 0000A206 014097BE 005513E7 06010000 [[email protected].....]
... ...
... ...
... ...
18810080 00000000 00000000 00000000 00000000 [................]
Repeat 502 times
18811FF0 00000000 2C000000 31010101 13E70601 [.......,...1....]
Block header mp: 0x014097be
Object id on Block? Y
seg/obj: 0xd10a csc: 0x00.5513bd itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x14097b9 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0006.01b.00000c9d 0x0080142b.088a.21 --U- 1 fsc 0x0000.005513e7
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
data_block_mp,data header at 0x18810064
===============
tsiz: 0x1f98
hsiz: 0x14
pbl: 0x18810064
bdba: 0x014097be
76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f93
avsp=0x1f7b
tosp=0x1f7b
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0x1f93
block_row_mp:
tab 0, row 0, @0x1f93
tl: 5 fb: --H-FL-- lb: 0x1 cc: 1
col 0: [ 1] 31
end_of_block_mp
另外，檢查它的基礎信息，這時obj和objn是相同的，都是ojb$表中對應的object#。
會話之間的臨時表數據是否可以復用？
以上的問題應該可以告一個段落了。下面我想到另外一個問題：如果各個會話的寫入臨時表中數據都一樣，那麼會話之間的數據能不能復用呢（即從其他會話的buffer cache中得到一份數據拷貝，而不需要讀寫臨時表空間）？
其實，這個問題應該可以通過一個比較簡單的測試來推斷：
1. 在兩個不同的會話中分別向臨時表插入數據：
INSERT INTO PGA_TEST VALUES(1, 1, 1);
2. 然後刷新buffer cache，將buffer中的數據都寫入到磁碟中去：
ALTER SYSTEM FLUSH BUFFER_CACHE;
以上語句之適用於10g，如果是9i，可以用下面的語句：
ALTER SYSTEM SET EVENTS 『IMMEDIATE TRACE NAME FLUSH_CACHE』;
3. 分別在兩個會話中查詢臨時表：
· SESSION 1:
SQL> SET AUTOT TRACE
SQL> SELECT * FROM PGA_TEST;
Execution Plan
----------------------------------------------------------
Plan hash value: 30787903
--------------------------------------
| Id | Operation | Name |
--------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS FULL| PGA_TEST |
--------------------------------------
Note
-----
- rule based optimizer used (consider using cbo)
Statistics
----------------------------------------------------------
165 recursive calls
0 db block gets
20 consistent gets
7 physical reads
0 redo size
6533 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
1 rows processed
可以看到第一個會話產生了physical read，顯然是從臨時數據段上讀取了數據。
再在這個會話上查詢一次：
SQL> /
Execution Plan
----------------------------------------------------------
Plan hash value: 30787903
--------------------------------------
| Id | Operation | Name |
--------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS FULL| PGA_TEST |
--------------------------------------
Note
-----
- rule based optimizer used (consider using cbo)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
6533 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
可以看到，以及沒有physical read了，這時不是動臨時段上讀取數據了，而是直接讀取buffer cache了。
· SESSION 2:
SQL> SET AUTOT TRACE
SQL> SELECT * FROM pga_test;
Execution Plan
----------------------------------------------------------
Plan hash value: 30787903
--------------------------------------
| Id | Operation | Name |
--------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS FULL| PGA_TEST |
--------------------------------------
Note
-----
- rule based optimizer used (consider using cbo)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
3 consistent gets
2 physical reads
0 redo size
6533 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
請注意，盡管SESSION 1已經是從buffer cache中讀取數據了，但是SESSION 2還是有physical read，說明它還是從自己所分配到的臨時段上讀取的數據，而不是copy其他會話的！
再作一次查詢：
SQL> /
Execution Plan
----------------------------------------------------------
Plan hash value: 30787903
--------------------------------------
| Id | Operation | Name |
--------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS FULL| PGA_TEST |
--------------------------------------
Note
-----
- rule based optimizer used (consider using cbo)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
6533 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
這時就是從它自己的buffer cache中讀取數據了。
推論2：每個會話在第一次INSERT是分配臨時段，他們的數據讀寫是完全獨立的，不會有任何聯系，即使他們的數據內容完全一樣。
我們再與普通表進行對比：
在第一個SESSION中查詢普通表：
SQL> SELECT * FROM pga_ttt;
Execution Plan
----------------------------------------------------------
Plan hash value: 3071005808
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 52 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS FULL| PGA_TTT | 1 | 52 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------
Statistics
----------------------------------------------------------
163 recursive calls
0 db block gets
24 consistent gets
15 physical reads
0 redo size
407 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
1 rows processed
這時產生了physical read，說明數據是從磁碟讀取的。
再在第一個SESSION查詢這張表：
SQL> SELECT * FROM pga_test;
Execution Plan
----------------------------------------------------------
Plan hash value: 30787903
--------------------------------------
| Id | Operation | Name |
--------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS FULL| PGA_TEST |
--------------------------------------
Note
-----
- rule based optimizer used (consider using cbo)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
6533 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
希望對你有幫助。
4、zblog的titleseo插件如何去除文章分類標題
安裝了Zblog的Titleseo插件之後網站日誌標題上面還有一個文章分類標題,我們又會感覺這個是多餘的。如果你也是這樣想那就我教你動手把他去掉把。我們可以使用以下方法去除掉。
未修改顯示: Titleseo插件去除文章分類標題 - 網站相關 - 蜘蛛虎'Blog
修改後顯示: Titleseo插件去除文章分類標題 - 蜘蛛虎'Blog
首先大家先找到TitleSEO插件的所在目錄，z-blog的所在根目錄下---plugin目錄下--TitleSEO文件包，在這個文件包里有兩個文件，分別是include.asp 和plugin.xml 。include.asp是該插件的主程序，plugin.xml文件為插件信息。我們一個方法是通過FTP軟體 下在include.asp這個文件到本地進行修改，可以用記事本、DW等編輯軟體（備註：注意你的編碼規則）。另一方法就是在博客的管理後台的文件管理里進行編輯修改。
我們打開include.asp這個文件，找到下面這段代碼：
" & articleCategoryName & " <#ZC_MSG044#>
找到該段代碼之後我們去掉保存即可,（注意保存之後先要把Titleseo插件停用然後上傳了在啟用）上傳覆蓋之後重建即可了