--oracle的日志和控制文件恢复
昨天下午一直到今天下午，一整天的时间经历了一场Windows优化大师的带来的“恶梦”，本不该怪罪这位“大师”的，原因在于自己用了这位“大师”，希望使用oracle的朋友在使用它时要注意一些问题。不然让它删除log和dmp文件。有可能大家都知道了，不过我还是第一次遇到，下面把这期间发生的事情讲给大家听：
昨天下午觉得系统比较慢，想起了Windows优化大师，于是乎下了个最新版安装、运行、“优化”，果然系统里删除了好多“垃圾”(在不知情之下，这些所谓的垃圾包括有用的注册表、珍贵的Oracle备份文件.dmp)。
“优化”之后，我的Oracle起不来了。怎么办？于是：
1）遂google了一下，发现优化大师会优化imagePath注册表，于是到注册表里去改。改完后重启，Oracle 仍然不能连接，没办法
2）系统还原吧，还原后仍然不能用，难道不是注册表的问题？没办法
3）新建了一个实例，准备找来刚刚备的Dmp文件恢复。晕！.dmp文件哪里去了？难道隐藏了？解开隐藏属性。汗！仍然没有？
我一拍脑袋，想起了“优化”大师干掉的吧，系统又还原了，怎么办？电脑里上百个.dmp文件都没了，十几年的备份。由于前天备份的硬盘坏了，格式化后还没有来得及把.dmp文件备到新硬盘里去。也就是说“大师”可能杀了我们十几年的资料。于是：
1）要么恢复.dmp文件
2）要么修复oracle。但是：
找来easy-recover和R-studio两个硬盘恢复软件，把.dmp文件恢复出来，但是导入数据时总是出现"未知的字符集"，google后发现并非字符集出问题，而是文件恢复有问题，打电话给硬盘恢复公司，说要重组dmp文件，需要十几万或几万。只有选择第2）套方案修复oracle了。我对oracle也是一知半解，没有做过恢复工作，所以绕了好多弯。
先看alter.log日志文件吧，发现找不到重做日志文件red01.log和red02.log。再次崩溃！“优化”大师把我的log日志文件也给删除了！怎么办？QQ群里的朋友提示:重建日志文件了，网上找来了很多办法，做了一晚，怎么也不成功，毕竟我是二把刀！在痛不欲生的情况下，第二天一大早，找到了一位oracle数据库管理员，请教了一番，他告诉我只要表空间文件还在控制文件和日志文件坏了都是可以恢复的，终于在他的指导下我完成了数据库修复工作，下面这个方面比网上一些方法要简单一些，我把它记下来供自己查阅也供遇到此类事件的朋友使用。
背景描述：oracle实例A的日志文件被误删除，同时因为后期修复过程中的误操作把控制文件也给破坏了。解决思路是：新建一个干净的实例，把坏掉实例的表空间数据文件倒进干净的实例中，并重新建立日志与控制文件的关联。具体做法如下：
1）新建一个实例B（D:\ORACLE\ORADATA\B\），到“服务”里停止实例B；
2）把实例A所有的.dbf文件拷贝到实例A里
3）“服务”启动实例B；
4）进入DOS，
c:/>sqlplus /nolog
sql>connect /@instancename as sysdba;
sql>startup ummount;
--下面是关键的一步，建立控制文件的关联
sql>CREATE CONTROLFILE REUSE DATABASE "B" RESETLOGS NOARCHIVELOG
-- SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 'D:\ORACLE\ORADATA\B\REDO01.LOG' SIZE 100M,
GROUP 2 'D:\ORACLE\ORADATA\B\REDO02.LOG' SIZE 100M,
GROUP 3 'D:\ORACLE\ORADATA\B\REDO03.LOG' SIZE 100M
-- STANDBY LOGFILE
DATAFILE
'D:\ORACLE\ORADATA\B\SYSTEM01.DBF',
'D:\ORACLE\ORADATA\B\UNDOTBS01.DBF',
'D:\ORACLE\ORADATA\B\CWMLITE01.DBF',
'D:\ORACLE\ORADATA\B\DRSYS01.DBF',
'D:\ORACLE\ORADATA\B\EXAMPLE01.DBF',
'D:\ORACLE\ORADATA\B\INDX01.DBF',
'D:\ORACLE\ORADATA\B\ODM01.DBF',
'D:\ORACLE\ORADATA\B\TOOLS01.DBF',
'D:\ORACLE\ORADATA\B\USERS01.DBF',
'D:\ORACLE\ORADATA\B\XDB01.DBF';
--关于DATAFILE里的内容，需要大家自己根据情况修改。
sql>shutdown
sql>startup mount
sq;>alter database open resetlogs;
5)这样应该就可以了，如果不行，关闭，重新连接应该就可以了。
经历这次事件，体会以下几点：
1）做开发和数据库管理的人不可以随便去使用一些软件，使用时更要仔细检查它的功能，阅读文档。
2）以前学的oracle知识大多一知半解，也很少去应用，这次的折腾以成功结束，所以对oracle有了更多的体会，也更喜欢这个数据库。
3）备份工作一定要持之以恒，不能只备在硬盘和活动硬盘里，还要备在光驱里，建立归档制度。
4）遇到困难时，热心的朋友真是多啊。网上的朋友和朋友介绍的朋友都很热心，对我的无知给给予了很多理解、同情和帮助。
近日收到导师关于论文答辩的Email，由于在职学习，时间总是不够用，加上懈怠，论文工作期限已近一年了。然而论文的进展才到一小半而己，只有利用夜里开工加班了。目前的论文是一套B/S系统，基于.net的评审系统的研究与开发。前两天，与Tony Qu在msn上chat时，受到启发，需要更多地将设计模式应用的内容扩展到论文中，既然是采用asp.net2.0，那么Provider模式自是重点。Tony给了我一大堆好文链接，正在加油学习，另外，微软asp.net官方网站推荐的startkit中，有一个项目叫做TheBeerHouse对Provider有很好的讲解，而且是一套较为完整的asp.net学习案例，现在已经读到Charpter5了，再有一个星期叫差不多学习完。准备近期能逐步将一些模式、结合TheBeerHouse、Petshop以及我现在的论文，写一些文章。
阅读之所以开心，是因为没有时间去计较平日里的不快和细节，享受作者思想的洗礼，眼前变得开阔，平静且激动。年初读的几本书总让我自我陶醉，信心百倍地面对人生，比如托夫勒的《第三次浪潮》、德鲁克的《卓有成效的管理者》。这些书读罢时隔也有一两个月了，读的时候心情总是激动，我在我的人生中追逐着我的真理，然而价值观总是不停摇摆，总想保留“属于自己的”一些不变的想法经常会受到大众的价值的影响，使我迷惑于这个世界。然而在阅读这些大师的作品时，总能找到放大“属于自己的”那一部分信念，这让我激动，使我找到了更多的理论支持，坚持自己现在走的路，并且找到校正自己的坐标。
如果您还没有阅读本系列开篇《CardViewer项目体会系列文章》，建议花些时间了解一下。
为什么重要：如果软件难于使用，如果它迫使你犯错误，如果它阻止你通过努力达到目标，你将不会喜欢它，不管它展示了什么计算机能力和提供了什么功能。因为界面影响用户对软件的感觉，因此，它必须是正确的。--Entry from 《Software Engineering--A practitioner's Approach》
废话：前一篇 CardViewer系列之杂篇--成功是个贫乏的教师 谈到，经与用户的一次失败交互找到了主要原因是在UI方面，所以一直希望从理论角度来解释实践以及提升实践能力，毕竟，理论是实践之后的产物，所以对于后人来讲，实践之后获得的理论才是有生命力以及生命的延续力（还原以及创造）。近几日重温了《Software Engineering--A practitioner's Approach》的有关章节，并阅读了教材中推荐的一些读物，如Theo Mandel的著作的第五章《The Golden Rules of User Interface Design》，有了一点体会和的认知。
UI设计的概念：用户界面设计在人和计算机间创建一个有效的通信媒介。遵循一组界面设计原则，设计任务需标识界面对象和动作，然后创建屏幕布局，形成用户界面原型的基础。
界面设计不只是美工：初次接触的UI design这个词汇时，对它的理解是如何把用户交互的界面（图形）设计的漂亮，对，界面设计基本上等同于美工，如同网站建设中的CSS和Skin。天啊，是这个名字给我的误解，我不是也不善美工，所以这不是我关心的内容，把它交给专业的美工吧。如果我们了解一下设计模型和用户设计过程是怎么一回事，就应该改变这种观点。
设计模型的种类：分四种。软件工程师创建设计模型；人员工程师（或者也是软件工程师）建立用户模型；终端用户在脑海里对产生的映名称为用户的模型或系统感觉；系统的实现者创建系统映像。前篇中涉及的问题，主要体现在用户模型与用户的系统感觉发生的冲突，这必然导致的冲突和交互失败。因为四种模不可避免地会有差距，我们要做的是减小差距。初期建立的用户模型更多地顾及到软件的设计而非用户，实际上，用户的背景性别年龄以及使用掌上电脑的熟练程度是把握调适模型平衡的关键因素，对用户以及任务的把握显得至关重要。
用户设计过程：用户、任务和环境分析及建模；界面设计；界面构造；界面确认。不难看出，界面设计的工作似乎伴随到软件需求分析和设计甚至更多过程的整个周期，如果界面设计时不能正确把握任务和用户以及环境，那么设计将会不断修改甚至推翻。如掌上电脑不同于PC，甚至与smartPhone的特征也不尽相同，手写输入法的使用以及用户偏好使用，不同PPC的屏幕大小的细微差别，是使用多个窗体还是使用一个窗体多个面板或他控件，不同年龄人群适合不同的字体大小，交互方式的难易程度，提供多种选择模式以适合不同用户分类（新手、对系统有了解的中级用户，对系统有了解的经常用户）。
美工只是界面设计的一个重要的部分，更多的是用来提升亲和力和感染力、舒适度。而非UI的大部分。
界面设计文章推荐：我想如果你有空拜读一下Theo Mandel的著作并开发或参与过任何一个完整的项目（不管项目的大小，只要完整），一定会受益良多。其中最为著名的就是以下三条黄金规则（原著中对这三条原则进行的丰富的解释，这里列出条目，详细内容不再copy，有兴趣的话点这里下载PDF）：
- Place Users in Control
- Reduce Users' Memory Load
- Make the Interface Consistent
说明：未标示Entry from 的灰色字体表示摘录的原文及翻译内容，原文及链接已经给出。
近几天一直在学习Terrylee/的有关模式的系列文章，受益不小，另外， 也跟我谈到过Mobile Client Software Factory的内容，感觉很值得研究，所以希望与大家一起研究并交流。
一部不是很热的老美剧《实习医生格蕾》让我回想起六年前做实习医生的幕幕往事。格蕾进入实习医院的第一幕是手术台和竞争伙伴，他们渴望获得展示的机会但又遇到重重挫折，他们渴望给病人已最大的安慰却不得不面对手术失败受到的谴责，他们象青苹果一样稚难却又精神饱满，他们时而徘徊自己的选择却又互相共勉当初的信仰。
六年前我也是一名实习医生，我渴望以最快的速度站在手术台优雅地操作手术刀，我满心幸福地听到建立起友谊的病人尊敬地叫我医生，我曾面临第一次单独处理急症时的恐惧，也曾经为处理完一件小小的医疗事件而兴奋地一夜不眠。竞争伙伴即是对手也是共勉的朋友，压力、快乐、安慰、一起有过痛苦的选择、一起感受成功的幸福，有时你不得己你要击败朋友并承受朋友变成我的假想敌，但是最终我们还是真诚地拥抱。我们一起用我们的所做追求着技能，思索着职业的哲理，思索着病人与医生，病人与病人，医生与医生......
如今已经不再是一名医生，但是我感激着那时的一切和一切......
本文尚属片断式的个人想法，或文过饰非，或自作多情，不敢苟求认同。旨在：希望博客园“资本”积累之初，不忘内功修炼，形成“园子文化”，方属长久之道。谨代表“我想出一份力”。
引言：
我喜欢的词汇。相比“加入”，更喜欢“参与”，我“参与”博客园社区，这样的话，我将参与对她的雕琢，并且不需要有意识地掩饰我的无知。相比“接收”，更喜欢“选择”，我“选择”了博客园社区，我选择她的理由很简单，她“承诺”培养我，而不是成为传说中的“点击率”，这种承诺是非语言的，而是潜在的“文化”，或许现在将之称为文化还为时过早，不过她正渐渐形成…...
园子里住的人。园子里有男有女，有老有少，我就是个老、男人，29岁的中华人民共和国男性公民，通过各种媒体，我们成为了一家人。园子里有来淘宝和献宝的，有来取经和传经的，我们互相激励，在个人成长中实现共同愿景。园子里住着不计报酬的贡献者和满怀感激的求学者。园子里住的人有不同的分工，或传播知识，或组织知识，或管理知识，拟或其它。园子还住着dudu，他的为人是谦和以及热情的，一次我们在msn里交流，当我赞许“博客团队”的形式时，dudu非常谦虚的表示团队功能相对较弱，需要完善。园子里住着太多的优秀作者，他们作为园子成长和发展必不可少的个体单元――“人才”，在我们的视野中成长并帮助我们成长，园子里住的这些人就是对我的“承诺”。
用数字说明问题就一定准吗？园子里有数字统计功能，站长联盟，static服务都提供了统计功能，看着积分数字在增加，排名的数字在减小，我乐在其中，并且号召不懂.net的朋友来增加我的点击率（呵呵，献丑了），可是，这远不如沉下心来写一篇文章来得有意义，要知道写出一篇文章往往不是把你的知识的记录下来，因为通过总结和取经对比写出来的文章会得到写作之前你所不知道的许多知识。换个角度，博客园如果只注重人头数、点击率、随笔文章数，那么同样，这远不如我们坐下来贡献自己的“有价值”的文章并沉淀出新的思想（这里所指的对“价值”的评价应该是客观的，由于文化知识和技术能力背景的差异，不可能以学术成就的眼光去评价其价值，那样的话，把博客园更名为MSDN好了，我认为凡是个人经过学习，认真分析，对比总结，助于个人和他人学习，并形成较好的文字组织就应该是有价值的）。
我以为：
组织文化与修炼内功。想要形成“管道”并持久发展，不可以只关注点击率，更重要的是内在建设，也就是形成组织文化（企业文化，Corporate Culture或Organisational Culture，英文的直译称为组织文化），这个近几年在管理学铺天盖地之后带来的词汇，在国内各业界属于有几年历史的新概念，逐渐被形成一定规模的组织所认可，因为它带来了实质的推动力。
良好的基础：主题定位以及人脉。有了文章数目攀升以及人脉的形式，博客园已经是一个具备相当规模的社区了，“专注于.net”这个标语使得我们的社区轻松地建立起了“特色”，“博客本身”的特点以及形式上的无政府状态、宽松的自由秩序，参与者的自觉约束和无私贡献，无疑使得社区资本积累的初步成功变得理所当然。这正是博客园现在所拥有的良好基础，同时也是各位和我所欣慰的。
这是我们要考虑的问题吗？我想是的。企业的基本要素是生产力，企业文化是企业发展的内功，企业文化的核心内容是价值观，价值观是建立企业战略的思想根源，企业战略是决定企业成败的关键因素。如果我们一味钻研细节是看不到这一点的。“我们不是商人和企业主，我们只关心技术，我们为什么要关心这些？”我想有人会这样说。可是，考虑一下，你、我、他这个单元个体组成了什么了？回答是：组织成为一个社区。对，是什么让我们成为社区一员并乐哉于此呢？回答是：渴求知识，寻找交流空间。没错，这样的话，我们与博客园的关系就是鱼水关系，这个社区的生产力就是在碰撞中产生新知识（好比苹果与思想的不同：我有1个苹果，给你1个我剩下0个；我有1个思想，给你1个，我有1个，你也有1个，甚至我们会碰撞出超过2个以上的思想，那么思想的总和将>=2）。
留给我和同样想法的朋友的问题。我敢肯定地说，组织文化的建设无疑有利于内功的修炼，有利于形成“管道”。但是对于属于这片领域的价值观是什么？如何形成这个价值观？如何提出发展的战略规划？对于现在正处于从事技术工作的大家来说，有一天你将会担任项目经理、企业主以及更高职位的角色，那么不如现在就暂且跳出圈子思考一下这些问题。以上有些想法源自于我对工作的思考，但是觉得对博客园建设同样有效。
本文仅提出一些务虚的标语和未成形的框架，尚无可操作性的建议建言，并将继续思考......