记录WordPress又一次恢复:备份真的很重要

        继上一次Blog经历一次惨痛的恢复经历之后,前几天站点所在空间服务器租用时间到期,导致Blog中止访问数天。

        如果重新续费hostmonster主机空间的话,可以立即恢复访问,但是折扣较低,不太换算。如果更换主机服务器的话,就不得重新安装、配置WordPress及本站所用的插件,当然了,这些都不难,很快就能搞定。然后用备份恢复出数据,头痛的是手上没有最近最新的备份。

       最后,忍痛割爱,找到一份4月26号的MySQL数据库的备份,这已经是最近最新的一次备份了,不得以,只好拿这个恢复了,恢复的结果就是现在这个样子。吃一堑长一智,重新执行了一次备份,并且配置了自动备份,以及更新WordPress从2.8.4到目前的最新版本,把有更新的插件也全部更新了。

       附:由于站点空间服务器出现问题导致站点暂停访问,在此向关注本站点的所有朋友们表示歉意。丢失的一部分数据,我尽可能的在最快时间内补充出来。

       感谢各位互联网上的朋友长期以来对于本站点的关注,多谢!:)

The Google Chrome shortcut

1 窗口和标签页快捷键:

Ctrl+N 打开新窗口
Ctrl+T 打开新标签页
Ctrl+Shift+N 在隐身模式下打开新窗口
Ctrl+O,然后选择文件 在谷歌浏览器中打开计算机上的文件
按住 Ctrl 键,然后点击链接 从后台在新标签页中打开链接,但您仍停留在当前标签页中
按住 Ctrl+Shift 键,然后点击链接 在新标签页中打开链接,同时切换到新打开的标签页
按住 Shift 键,然后点击链接 在新窗口中打开链接
Alt+F4 关闭当前窗口
Ctrl+Shift+T 重新打开上次关闭的标签页。谷歌浏览器可记住最近关闭的 10 个标签页。
将链接拖动到标签页内 在指定标签页中打开链接
将链接拖动到两个标签页之间 在标签页横条的指定位置建立一个新标签页,在该标签页中打开链接
Ctrl+1 到 Ctrl+8 切换到指定位置编号的标签页。您按下的数字代表标签页横条上的相应标签位置。
Ctrl+9 切换到最后一个标签页
Ctrl+Tab 或 Ctrl+PgDown 切换到下一个标签页
Ctrl+Shift+Tab Ctrl+PgUp 切换到上一个标签页
Ctrl+W 或 Ctrl+F4 关闭当前标签页或弹出式窗口
Alt+Home 打开主页

2 地址栏快捷键在地址栏,进行下列操作之一:

键入搜索字词 使用默认搜索引擎进行搜索
键入网址中”www.”和”.com”之间的部分,然后按 Ctrl+Enter 为您在地址栏中输入的内容添加”www.”和”.com”,然后打开网址
键入搜索引擎关键字或网址,按Tab 键,然后键入搜索字词 使用与关键字或网址相关联的搜索引擎进行搜索。如果谷歌浏览器可以识别您要使用的搜索引擎,则会提示您按 Tab 键。
F6 或 Ctrl+L 或 Alt+D 选中网址区域中的内容
键入网址,然后按 Alt+Enter 在新标签页中打开网址

3 打开谷歌浏览器各功能的快捷键:

Ctrl+B 打开和关闭书签栏
Ctrl+Shift+B 打开书签管理器
Ctrl+H 查看”历史记录”页
Ctrl+J 查看”下载”页
Shift+Escape 查看任务管理器
Shift+Alt+T 将焦点设置在工具栏上。使用键盘上的向右和向左箭头,可导航至工具栏上的不同按钮。

4 网页快捷键:

Ctrl+P 打印当前页
Ctrl+S 保存当前页
F5 重新加载当前页
Esc 停止加载当前页
Ctrl+F 打开”在网页上查找”框
点击鼠标中键或滚轮 激活自动滚动。当您移动鼠标时,网页会根据鼠标的移动方向自动滚动。
Ctrl+F5 或 Shift+F5 重新加载当前页,但忽略缓存内容
按住 Alt 键,然后点击链接 下载链接
Ctrl+G 或 F3 查找与您在”在网页上查找”框中输入的内容相匹配的下一个匹配项
Ctrl+Shift+G Shift+F3 查找与您在”在网页上查找”框中输入的内容相匹配的上一个匹配项
Ctrl+U 查看源代码
将链接拖动到书签栏 将链接加入书签
Ctrl+D 将当前网页加入书签
Ctrl++,或者按住 Ctrl 键并向上滚动鼠标滚轮 放大网页上的所有内容
Ctrl+-,或者按住 Ctrl 键并向下滚动鼠标滚轮 缩小网页上的所有内容
Ctrl+0 将网页上的所有内容都恢复到正常大小

5 文字快捷键:

选中内容,然后按 Ctrl+C 将内容复制到剪贴板
将光标置于文本字段中,然后按 Ctrl+V 或 Shift+Insert 从剪贴板粘贴当前内容
将光标置于文本字段中,然后按 Ctrl+Shift+V 从剪贴板粘贴当前内容的纯文本部分
选中文字字段中的内容,然后按 Ctrl+X 或 Shift+Delete 删除内容并将其复制到剪贴板

6 更多快捷键:

Backspace,或同时按住 Alt 和向左箭头键 转至标签页浏览历史记录中的上一页
Shift+Backspace,或同时按住 Alt 和向右箭头键 转至标签页浏览历史记录中的下一页
Ctrl+K 或 Ctrl+E 将”?”置于地址栏中。在”?”之后键入搜索字词,以使用默认搜索引擎进行搜索。
将光标置于地址栏中,然后同时按住 Ctrl和向左箭头键 跳到地址栏中的前一个字词
将光标置于地址栏中,然后同时按住 Ctrl和向右箭头键 跳到地址栏中的下一个字词
将光标置于地址栏中,然后按住Ctrl+Backspace 删除地址栏中的上一个字词
空格键 向下滚动网页
Home 转至网页顶部
End 转至网页底部
按住 Shift 键并滚动鼠标滚轮 在网页上水平滚动

How to backup the Oracle Control File?

How to backup the Oracle Control File ?

There are two approaches: you either generate a binary image of the Control File, or you generate a text file script which will re-generate a Control File when run as a SQL script.

To create the binary image, issue the command ALTER DATABASE BACKUP CONTROLFILE TO ‘C:\SOMEWHERE\CONTROL01.BKP’; (obviously pick a destination and file name that are suitable for your needs).

To create the text script version, issue the command ALTER DATABASE BACKUP CONTROLFILE TO TRACE. That causes a file to be written to wherever your init.ora parameter USER_DUMP_DEST is pointing. The file name will be something like ‘ora_<some numbers>.trc’. You’ll have to track it down using the O/S date and timestamp (or you can take advantage of the fact that the “some numbers” bit is your Server Process ID Number -which you can determine from v$session and v$process).
The binary image is ready to work from the word go (with one hugely important proviso, of which more below).

The trace file is, however, a bit of a mess, and needs to be knocked into shape if it is to be of any use in a recovery situation. Firstly, it contains a whole heap of junk at the top (referencing your O/S, your Oracle version, dates and times and process or thread numbers). That’s got to go -which means deleting all of it, until the first line reads STARTUP NOMOUNT. Immediately before that line, you need a connect string, since you can’t ever issue the ‘startup’ command until you’ve connected as a Privileged User. Insert something appropriate, therefore (such as CONNECT / AS SYSDBA if using O/S authentication, or CONNECT SYS/ORACLE AS SYSDBA if using Password File Authentication). You may possibly also need to qualify the ‘STARTUP NOMOUNT’ line itself so that it references an appropriate init.ora (for example, STARTUP NOMOUNT PFILE=/SOMEWHERE/NON-DEFAULT/INIT.ORA). Other than that, the file is fine, and useable.

Under no circumstances should you ever need a backup of your Control File, of either type. You’d only use one if ALL copies of the Control File had become corrupt or had been destroyed (and the whole purpose of multiplexing your Control Files is to minimise those possibilities). But if that fateful day ever arrives, then you simply need to fire up Server Manager (or SQL Plus if using 8i or above), and issuing the command to run the trace file script (i.e., typing @name_of_script.ext). There’s no need to connect first -remember, that was the first line we added to the script earlier. If for some reason the Instance is already running, the script will fail -it needs a completely shut down system before it can do its stuff.

The trouble starts when you attempt to restore the binary version of the Control File backup. Because it was an exact, binary copy of a Control File, its SCN number will not agree with the SCN in the headers of all the data files -basically, the Master Clock is out of whack. You therefore have to issue the command “RECOVER DATABASE USING BACKUP CONTROLFILE;” to tell the system not to pay too much attention to the SCN of the Control File. Unfortunately, after you issue that command (and following any recovery that it might cause to take place), you must open the database with the command “ALTER DATABASE OPEN RESETLOGS;”.

That’s unfortunate, because the ‘resetlogs’ command basically forces the entire database to re-synchronise at time zero, which is fine for getting the database open, but is not exactly useful if you ever need to restore from your prior backups (taken when the database was at a time of, say, 10894329), or if you ever expect to be able to apply redo from priot archive logs (which were also taken when the database was at time 10894329 and earlier). Basically, a ‘resetlogs’ renders your database entirely vulnerable: there are no effective backups, and no effective archives. You are therefore supposed to immediately shut the newly-recovered database down, and perform a whole, closed backup of the entire database (which is not exactly a cheap option).

You might wonder why the use of the trace file does not cause this HUGE problem.  The answer is simple: it cheats. Contained within the trace file are locations of every data file in the system. When the file is run, it uses those locations to read the headers of all the data files, whereupon it picks the highest SCN it comes across as the one to write into the header of the Control File it is about to create. That means the re-constructed Control File is already in synchronisation with the data files, and no forced synchronisation to time Zero is therefore required.

So, what’s the best way of backing up the Control File? Answer: multiplex your Control Files so that a recovery is never needed in the first place. But if, despite that, you need some insurance, the Trace File is definitely the better way to go.  It doesn’t render your entire database exposed to failure, it doesn’t effectively trash all prior backups and archives, it works quickly, and well.

There’s only one proviso to this whole discussion: whatever backup method you choose, you need to keep it up-to-date.  Since the Control File contains pointers to the physical location of all data files and redo logs, any backup of that file needs to make sure that those pointers are accurate. Making a physical change to your database (for example, adding a new data file or tablespace, dropping a tablespace, moving or renaming a data file) will instantly render all prior Control File backups out-of-date.  Slightly unnervingly, changing a tablespace from read-write to read-only (or vice versa) also counts as a physical change to your database (because the Control File must always accurately identify any read-only data files).  After any of those operations, therefore, you need to take a fresh backup of the Control File.

It is always conceivable that you could edit a Trace File backup before using it to take account of any physical changes, but the syntax is not easy, and I don’t rate your chances of pulling it off. As for editing the binary copy -forget it!  Net result: keep taking the backups on a regular basis.  I usually recommend a chron job (for our NT friends, that’s an AT job!) which issues the ‘backup to trace’ command every night. It means you need a bit of house-keeping to avoid complete mayhem (and a million trace files) in the user_dump_dest, but it will guarantee a file which, at worst, can be used with the mere addition of a line or two to reference any data files created between the time the trace file was created and the time all Control Files went awol.

Note:How to backup the control file to trace ?

1.SQL>alter database backup controlfile to trace;
Database altered.
2.SQL>show parameter USER_DUMP_DEST;
…………..
3.SQL>select spid from v$process p,v$session s
where p.addr=s.paddr
and s.status=’ACTIVE’
and s.username=’SYS’
;

4.Then goto the USER_DUMP_DEST directory (we get it on step 2),view the file named  ora_<SID>_<spid>.trc .It’s contents are what we needed.After modified the file,we can use it to recreate a new controlfile.

—-End

user_tab_modifications

USER_TAB_MODIFICATIONS describes modifications to all tables owned by the
current user that have been modified since the last time statistics were gathered on the

USER_TAB_MODIFICATIONS describes modifications to all tables owned by the current user that have been modified since the last time statistics were gathered on the tables. 使用User_tab_modifications来获取数据表的DML过程: 1,SQL> select * from USER_TAB_MODIFICATIONS ; no rows selected 2,  SQL>insert into test values(1,'Asher'); one row inserted 3, SQL>select * from USER_TAB_MODIFICATIONS ; no rows selected Why? just waiting for a moment,or after I've executed the procedure【dbms_stats.flush_database_monitoring_info()】,we will get the expected result. 4, SQL> exec dbms_stats.flush_database_monitoring_info(); PL/SQL procedure successfully completed. 5,SQL> select * from USER_TAB_MODIFICATIONS ; The correct result will appears.

史上最伟大的12款软件排名 DB2名列第二

美国《信息周刊》日前刊文评出了有史以来最伟大的12款软件。结果,Unix操作系统脱颖而出,排名首位。   据榜单显示,继Unix之后,Java语言排名第五;苹果Macintosh系统位居第八,而微软的Excel电子表格和Google搜索分别列居第九和第十一位。   有趣的是,1988年11月2日爆发的Morris蠕虫也榜上有名。当时,几天之内就有6000多台互联网服务器被感染而瘫痪,造成的经济损失超过一千万美元。   以下为有史以来最伟大12款软件排名:   1. Unix操作系统   2. IBM System R-1983年以DB2的形式进入商业市场   3.基因排序软件-美国基因组研究所(IGR)   4. IBM System 360系统   5. Java语言   6. Mosaic浏览器-第一款图形界面浏览器   7. Sabre系统-美国航空公司的信息查询系统   8.苹果Macintosh系统   9.微软Excel电子表格   10.阿波罗宇宙飞船导航系统   11.Google搜索排名   12.Morris蠕虫-造成的经济损失超过1000万美元 —– Original From:http://www.eygle.com/digest/2006/11/the_best_12_software.html

Start from now on…

Yeah,as the title described.After several hours configuring(though it is simple,i am an newbie *^__^*  ),I established this site.And now i will log all my notes about exploring and studying Oracle,to share it with all my deer audience. By the way,  thanks to my friend Jia guoqing,without his generous help,I cann't write any words here.He efford the host to me free,Many thanks to you.