WordPress主机的选择：国外主机的优势
2007/03/3 | BlogsDiy · 3 回复
在为WordPress博客寻找主机时，首先面临的便是国内主机与国外主机的选择，虽说网站的地理位置在何处，对访问用户而言是无所谓的，用户关心的只是网站的产品、服务或信息，只要网站内容丰富，访问速度尚可，便不会有任何问题。而理论上看，网站服务器应在物理中保持与访问用户的最短距离，这样访问速度最有保障，因此，一般有这样的说法，即如果您的博客/网站使用英文或其他语言、主要面向国外用户，那么，选择国外主机理所当然；反之，便应选择国内主机。
但囿于各种现实条件，类似上面的判断其实很难说是正确的，下面让我们具体地分析一下。
价格
国内主机市场不知道是因为尚不完善还是竞争不足，价格始终居高不下，往往一个简单的仅支持单域名/几百兆空间的虚拟主机价格便到了每年五六百元的档次，而且，性能往往没有基本的保障，一台P4、IDE硬盘的“伪”服务器上就敢放几百甚至上千个网站。
而相对应地，国外虚拟主机的价格要较得多。这即与国外尤其是美国的互联网资源特别是带宽资源较为丰富、成本较低有关，也与国外主机市场的激烈竞争以及主机商的规模较大有关，毕竟，规模大便可以有效地降低成本。
当然，另一点可能促使我们选择国外主机的理由便是，目前国内主机市场上Unix/Linux主机价格反而高于Windows主机，这对于欲让自己的WordPress博客实现全部设计功能的用户而言意味着要付出更多的费用。
服务
上面所说的目前国内主机市场竞争不足的观点可能很多朋友并不接受，毕竟目前国内遍地都卖虚拟主机，不过，如果您仔细查看一下他们的资料，有多少出身/附属于类似于官老爷机构的电信、网通，究竟有几家主机商拥有自己的Data Center而不是在电信、网通机房租个位置摆放服务器，便能清楚这种竞争位于什么档次了。
相信在电信、网通机房租用过主机或托管服务器的朋友们都会对他们的服务有深切的体会，相比较而言，对财大气粗直接租用固定带宽的大型用户还好些，而对虚拟主机以及共享带宽的主机托管来说，其服务很多时候甚至可以说是可笑的：只要网络没断、能够连通便敢声称一切OK，但没办法，这就是官企的服务。
而处在真正市场竞争体制下的国外主机来说，服务是其生存与发展的最基本保证，当网站、主机出现问题时其必须在第一时间内解决。大多数的虚拟主机商会提供24 x7的技术支持，当然，这里的技术支持是指真正解决问题，而不是官办企业的官样文章、托辞乃至胡搅蛮缠。
至于国内主机服务、支持差的另一个可能原因在于，按照某些号称主机专家的言论如 “国内Windows平台应用较为普及因而人力成本较低所致”之类，可能的潜台词便是机房管理人员中Unix/Linux方面的专业技术人员不足或能力太差：如果他们自己也搞不清楚问题出在哪里，当然如何解决便无从谈起了。
访问速度
许多朋友对使用国外主机最大的担心便是访问速度。从技术角度看，这种担心是顺理承章的，毕竟，国内用户访问时要多了个国际出口的环节，何况，前段时间海缆被震断的事件，也让很多想要使用国外主机的用户望而却步。
但是，也必须清醒地看到，目前中国与国外特别是中美间的连接带宽仍在高速扩容——使用国外的虚拟主机速度并不似想象得那么慢，事实上，甚至要比很多国内主机快得多。——而多路海缆的铺设也会避免上次那样被地震后几乎完全中断的情况发生。而且，就象那句苦涩的笑话所说的，“在Internet上，最远的距离不是中国和美国，而是网通和电信”，使用国内主机时除非选择双线(电信、网通)，不然，总会有一半的朋友在访问时处于极其痛苦的境地，而一般而言，使用国外主机则可有效地解决这个电信网通互访困难的问题，毕竟无论电信还是网通都有充足的国际带宽，当然，这也是个苦涩的“曲线救国”笑话。
国外主机的其他优势
免去繁琐的备案手续
对于不涉及政治、色情内容的网站，备案手续并不算繁琐，可直接在网上办理。但若按信息产业部的规定，严格说来，类似博客这样存在交互内容的网站，应属“电子公告”服务，而这则需“应向所在地通信管理局提出专项申请或者专项备案。获准同意后方可开展电子公告服务活动”，虽然目前可以说绝大多数博客未履行这道手续，但既然有这样的规定，也许哪天就会找上门来。
一旦手续牵涉到由人工办理，繁琐就成了必然……
较高的性价比
国外主机市场成熟规范，网络设施有保障，而且，目前一般都能提供免费域名、支持多域名可同时架设多个网站等，让您在投入时绝对有物有所值的感觉。
试用与全款返还
国外主机商一般能均有30天甚至更长期限的“原款奉还”政策，即在试用期内如果您不满意其产品、服务，可获得全额退款，这在相当程序保证了用户的利益。
这类承诺能够相信么？当然，只要您选择的不是草台班子，就根本不用担心，健全的法律保证了商家承诺的可靠性。
博客主机选择要点及策略
Wordpress主机的选择：主机平台
Wordpress主机的选择：主机类型
WordPress主机的选择：考虑因素
WordPress主机的选择：国外主机的优势
→ 版权声明
分类: 博客网站主机
2008/01/19
2007/12/10
ext3 became read only for journal corruption
*NOTE: I'm NOT SURE about the result of following operations! please backup all your data before execute it.
-----
The EL4 kernel is wacky when it comes the the I/O scheduler locking up and and causing ext3 to remount RO. Various hardware hiccups can cause it to go RO.
And when it does.. you need to tread lightly or you could lose everything.
If your ext3 filesystem had problems and remounted read-only, I would strongly advise /against/ simply fscking it. Often times when your filesystem has gone RO, it may have been that way for 30 minutes or more. Just rebooting or fscking is a great way to lose everything (i.e. everything being dumped into /lost+found/
Instead, I would recommend:
1) rebooting into a rescue CD environment (not allowing the rescue environment to mount or fsck your filesystems).
2) Nuke the ext3 journal:
tune2fs -O ^has_journal /dev/
(possibly doing the same for other problem partitions)
3) Do a fake fsck to see the extent of damage:
fsck -fn /dev/
(after checking things out.. use "-fy" once you're sure that it's safe)
4) Rebuild the journal w, "tune2fs -j /dev/
(rerun at least once until "clean" result is repeatable)
5) Mount and check things out,
"mkdir /mnt/tmp && mount -t ext3 /dev/ /mnt/tmp"
6) Gracefully umount & reboot:
"umount /mnt/tmp && shutdown -rf now && exit"
-----
The EL4 kernel is wacky when it comes the the I/O scheduler locking up and and causing ext3 to remount RO. Various hardware hiccups can cause it to go RO.
And when it does.. you need to tread lightly or you could lose everything.
If your ext3 filesystem had problems and remounted read-only, I would strongly advise /against/ simply fscking it. Often times when your filesystem has gone RO, it may have been that way for 30 minutes or more. Just rebooting or fscking is a great way to lose everything (i.e. everything being dumped into /lost+found/
Instead, I would recommend:
1) rebooting into a rescue CD environment (not allowing the rescue environment to mount or fsck your filesystems).
2) Nuke the ext3 journal:
tune2fs -O ^has_journal /dev/
(possibly doing the same for other problem partitions)
3) Do a fake fsck to see the extent of damage:
fsck -fn /dev/
(after checking things out.. use "-fy" once you're sure that it's safe)
4) Rebuild the journal w, "tune2fs -j /dev/
(rerun at least once until "clean" result is repeatable)
5) Mount and check things out,
"mkdir /mnt/tmp && mount -t ext3 /dev/
6) Gracefully umount & reboot:
"umount /mnt/tmp && shutdown -rf now && exit"
2007/12/08
僕の人工知能考え方
僕の人工知能考え方
人
人間の行動及び動機
勉強（生理維持、好奇心）
挑戦（？）
労働（生理維持）
繁殖（生理維持）
権力（生理維持）
動機
欲求（生理、安全、愛情、尊敬、自己実現）
人間の行動の実行
行動結果の判断と改善
人間思考の特徴
さえ動機があれば、色々と試していく。
うまくいくのとうまくいかないことがある。
進化と知能の違い
人
人間の行動及び動機
勉強（生理維持、好奇心）
挑戦（？）
労働（生理維持）
繁殖（生理維持）
権力（生理維持）
動機
欲求（生理、安全、愛情、尊敬、自己実現）
人間の行動の実行
行動結果の判断と改善
人間思考の特徴
さえ動機があれば、色々と試していく。
うまくいくのとうまくいかないことがある。
進化と知能の違い
人工智能 book list
1.《人工智能》（美）尼尔森 郑扣根译 机械工业出版社
2.《人工智能智能系统指南》（英文版·第2版） （澳）尼格内维特斯基（Negnevitsky,M.） 机械工业出版社
3.《人工智能：理论与实践》（美）迪安 等著，顾国昌 等译 电子工业出版社
4.《人工智能：复杂问题求解的结构和策略》（美）George F.Luger 著，史忠植，张银奎 等译 机械工业出版社
5.《游戏编程中的人工智能技术》（美）布克兰德 著，吴祖增，沙鹰 翻译 清华大学出版社
6.《人工智能游戏编程真言》（美）拉比（Rabin,S.） 主编，庄越挺，吴飞 译清华大学出版社
7.《人工智能智能系统指南》（英文版·第2版） （澳）尼格内维特斯基（Negnevitsky,M.） 机械工业出版社
2.《人工智能智能系统指南》（英文版·第2版） （澳）尼格内维特斯基（Negnevitsky,M.） 机械工业出版社
3.《人工智能：理论与实践》（美）迪安 等著，顾国昌 等译 电子工业出版社
4.《人工智能：复杂问题求解的结构和策略》（美）George F.Luger 著，史忠植，张银奎 等译 机械工业出版社
5.《游戏编程中的人工智能技术》（美）布克兰德 著，吴祖增，沙鹰 翻译 清华大学出版社
6.《人工智能游戏编程真言》（美）拉比（Rabin,S.） 主编，庄越挺，吴飞 译清华大学出版社
7.《人工智能智能系统指南》（英文版·第2版） （澳）尼格内维特斯基（Negnevitsky,M.） 机械工业出版社
2007/12/06
dba_tablesapce.ALLOCATION_TYPE
ALLOCATION_TYPE 这个值有3个选项：
1、system：一旦设定该值，next_extent将为空，只有extents值。该值是默认值。这个选项的最小是64K
2、user：一旦设定该值，就允许我们可以控制next_extent了。只有两种情况出现users：一是该ts是数据字典管理的；另外一个是该ts是从数据字典管理转移到local的（用dbms_space_admin.tablespace_migrate_to_local）
3、uniform：将标明所有的extent的大小将一致，temp表空间只能采用这个方式；以上两个情况的extent的大小将不一致；uniform中的默认值为1M
1、system：一旦设定该值，next_extent将为空，只有extents值。该值是默认值。这个选项的最小是64K
2、user：一旦设定该值，就允许我们可以控制next_extent了。只有两种情况出现users：一是该ts是数据字典管理的；另外一个是该ts是从数据字典管理转移到local的（用dbms_space_admin.tablespace_migrate_to_local）
3、uniform：将标明所有的extent的大小将一致，temp表空间只能采用这个方式；以上两个情况的extent的大小将不一致；uniform中的默认值为1M
Oracle RAC failover
SELECT FAILOVER_TYPE , FAILOVER_METHOD
FROM v$session WHERE sid = (SELECT sid FROM v$mystat WHERE ROWNUM = 1) ;
FROM v$session WHERE sid = (SELECT sid FROM v$mystat WHERE ROWNUM = 1) ;
增量追加备份：前滚镜像拷贝 explain
RUN {
RECOVER COPY OF DATABASE WITH TAG 'incr_update';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE;
}
增量追加备份：前滚镜像拷贝
ORACLE文档原文：Incrementally Updated Backups: Rolling Forward Image Copy Backups。
增量追加备份工作原理：首先创建一个文件镜像拷贝，然后定期把从上次镜像拷贝最大SCN以来变化的数据块追加到镜像拷贝文件中。增量追加备份可以达到快速恢复的目的，如果是每天进行增量追加的话，在进行恢复的时候，我们最多应用一天的REDO数据就可以完成恢复。
创建增量追加备份，格式如下：
BACKUP... FOR RECOVER OF COPY WITH TAG
一个基础的增量追加备份示例：简称basic脚本
RUN {
RECOVER COPY OF DATABASE WITH TAG 'incr_update';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}
为了理解上述脚本，我们先看一下如果没有数据文件拷贝和增量备份运行这两个脚本的情况。
1、如果没有LEVEL0备份或者备份文件拷贝，执行BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG...不能产生LEVEL1增量备份文件，但是RMAN会按照指定的tag在DATAFILE对应的目录下创建一分镜像文件拷贝。
2、如果没有LEVEL0备份或者备份文件拷贝，执行RECOVER COPY OF DATABASE WITH TAG...则生成一些信息但是不产生错误。
我们看一下整个basic脚本的执行情况：
第一次运行该脚本没有数据文件拷贝和增量备份所以执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'没有任何结果；执行BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE将产生数据文件的镜像文件拷贝。
第二次运行该脚本，由于第一次运行的时候BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG...命令产生一个镜像文件拷贝，但是没有LEVEL1的增量备份，所以执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'还是没有任何结果；执行BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE将产生LEVEL1增量备份。
第三次运行该脚本，执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'命令将把第二次执行该脚本产生的LEVEL1增量备份追加到镜像文件拷贝，同时又产生一个新的LEVEL1增量备份文件。
以后再执行该脚本都是把上次产生的LEVEL1的增量备份追加到镜像文件拷贝，然后再产生一个新的LEVEL1的增量备份文件。
如果需要恢复，我们首先恢复镜像文件拷贝和最后一次LEVEL1增量备份，最后应用REDO。
RECOVER COPY OF DATABASE WITH TAG 'incr_update';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE;
}
增量追加备份：前滚镜像拷贝
ORACLE文档原文：Incrementally Updated Backups: Rolling Forward Image Copy Backups。
增量追加备份工作原理：首先创建一个文件镜像拷贝，然后定期把从上次镜像拷贝最大SCN以来变化的数据块追加到镜像拷贝文件中。增量追加备份可以达到快速恢复的目的，如果是每天进行增量追加的话，在进行恢复的时候，我们最多应用一天的REDO数据就可以完成恢复。
创建增量追加备份，格式如下：
BACKUP... FOR RECOVER OF COPY WITH TAG
一个基础的增量追加备份示例：简称basic脚本
RUN {
RECOVER COPY OF DATABASE WITH TAG 'incr_update';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}
为了理解上述脚本，我们先看一下如果没有数据文件拷贝和增量备份运行这两个脚本的情况。
1、如果没有LEVEL0备份或者备份文件拷贝，执行BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG...不能产生LEVEL1增量备份文件，但是RMAN会按照指定的tag在DATAFILE对应的目录下创建一分镜像文件拷贝。
2、如果没有LEVEL0备份或者备份文件拷贝，执行RECOVER COPY OF DATABASE WITH TAG...则生成一些信息但是不产生错误。
我们看一下整个basic脚本的执行情况：
第一次运行该脚本没有数据文件拷贝和增量备份所以执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'没有任何结果；执行BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE将产生数据文件的镜像文件拷贝。
第二次运行该脚本，由于第一次运行的时候BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG...命令产生一个镜像文件拷贝，但是没有LEVEL1的增量备份，所以执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'还是没有任何结果；执行BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE将产生LEVEL1增量备份。
第三次运行该脚本，执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'命令将把第二次执行该脚本产生的LEVEL1增量备份追加到镜像文件拷贝，同时又产生一个新的LEVEL1增量备份文件。
以后再执行该脚本都是把上次产生的LEVEL1的增量备份追加到镜像文件拷贝，然后再产生一个新的LEVEL1的增量备份文件。
如果需要恢复，我们首先恢复镜像文件拷贝和最后一次LEVEL1增量备份，最后应用REDO。
ext3 filesystem had problems
The EL4 kernel is wacky when it comes the the I/O scheduler locking up and and causing ext3 to remount RO. Various hardware hiccups can cause it to go RO.
And when it does.. you need to tread lightly or you could lose everything.
If your ext3 filesystem had problems and remounted read-only, I would strongly advise /against/ simply fscking it. Often times when your filesystem has
gone RO, it may have been that way for 30 minutes or more. Just rebooting or fscking is a great way to lose everything (i.e. everything being dumped into /lost+found/
Instead, I would recommend:
1) rebooting into a rescue CD environment (not allowing the rescue environment to mount or fsck your filesystems).
2) Nuke the ext3 journal:
tune2fs -O ^has_journal /dev/
(possibly doing the same for other problem partitions)
3) Do a fake fsck to see the extent of damage:
fsck -fn /dev/
(after checking things out.. use "-fy" once you're sure that it's safe)
4) Rebuild the journal w, "tune2fs -j /dev/
(rerun at least once until "clean" result is repeatable)
5) Mount and check things out,
"mkdir /mnt/tmp && mount -t ext3 /dev/ /mnt/tmp"
6) Gracefully umount & reboot:
"umount /mnt/tmp && shutdown -rf now && exit"
And when it does.. you need to tread lightly or you could lose everything.
If your ext3 filesystem had problems and remounted read-only, I would strongly advise /against/ simply fscking it. Often times when your filesystem has
gone RO, it may have been that way for 30 minutes or more. Just rebooting or fscking is a great way to lose everything (i.e. everything being dumped into /lost+found/
Instead, I would recommend:
1) rebooting into a rescue CD environment (not allowing the rescue environment to mount or fsck your filesystems).
2) Nuke the ext3 journal:
tune2fs -O ^has_journal /dev/
(possibly doing the same for other problem partitions)
3) Do a fake fsck to see the extent of damage:
fsck -fn /dev/
(after checking things out.. use "-fy" once you're sure that it's safe)
4) Rebuild the journal w, "tune2fs -j /dev/
(rerun at least once until "clean" result is repeatable)
5) Mount and check things out,
"mkdir /mnt/tmp && mount -t ext3 /dev/
6) Gracefully umount & reboot:
"umount /mnt/tmp && shutdown -rf now && exit"
find oracle shared memory handle
ps -ef | grep vasdb | grep oracle | grep LOCAL
#memo the {pid}
sqlplus sys@op.. as sysdba
oradebug setospid {pid}
oradebug ipc
exit
cd {your udump dir}
ls -lt
vasdb_ora_xxxx.trc
grep Handle vasdb_ora_xxxx.trc
#you will find the memory handle.
#if you can start the secondary database to nomount.
#you can compare the too handle string and find out the difference.
the result of my server
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/oracle/app/oracle/product/10.2.0/db_1
System name: Linux
Node name: test
Release: 2.4.21-37.ELsmp
Version: #1 SMP Wed Sep 7 13:28:55 EDT 2005
Machine: i686
Instance name: orcl
Redo thread mounted by this instance: 0
Oracle process number: 15
Unix process pid: 23332, image: oracle@test (TNS V1-V3)
*** 2007-12-05 21:09:32.165
*** SERVICE NAME:() 2007-12-05 21:09:32.165
*** SESSION ID:(159.1) 2007-12-05 21:09:32.165
Received ORADEBUG command 'ipc' from process Unix process pid: 23483, image:
Dump of unix-generic skgm context
areaflags 000000e7
realmflags 0000000f
mapsize 00000800
protectsize 00001000
lcmsize 00001000
seglen 00200000
largestsize 0000000080000000
smallestsize 0000000000400000
stacklimit 0xbe0776e0
stackdir -1
mode 660
magic acc01ade
Handle: 0xccd9088 `/u01/oracle/app/oracle/product/10.2.0/db_1orcl'
Dump of unix-generic realm handle `/u01/oracle/app/oracle/product/10.2.0/db_1orcl', flags = 00000000
Subscribe to:
Posts (Atom)