2006年11月21日
--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）。
留给我和同样想法的朋友的问题。我敢肯定地说，组织文化的建设无疑有利于内功的修炼，有利于形成“管道”。但是对于属于这片领域的价值观是什么？如何形成这个价值观？如何提出发展的战略规划？对于现在正处于从事技术工作的大家来说，有一天你将会担任项目经理、企业主以及更高职位的角色，那么不如现在就暂且跳出圈子思考一下这些问题。以上有些想法源自于我对工作的思考，但是觉得对博客园建设同样有效。
本文仅提出一些务虚的标语和未成形的框架，尚无可操作性的建议建言，并将继续思考......
如果您还没有阅读本系列开篇《CardViewer项目体会系列文章》，建议花些时间了解一下。
简介：本节以我的三篇日记作为线索，讲述了项目过程中的一件不大不小的故事，也许你也曾经遇到或者正在经历。本节不涉及任何技术讨论，如果只对技术感兴趣请不要浪费您的宝贵时间在这篇随笔上。
2006年3月13日：今天很兴奋地将软件的半成品拿给客户负责人看，本以为会得到欣赏和赞许。但出乎我的意外，结果正好相反。理由是：过于复杂，与他们以前阅读纸张模式差别太大。他们提出：“停止开发，如果不能改变的话”。……
“停止开发”。回到办公室后，我沉默了一个小时，现在我已记不得当时心中的苦闷和对话，大概的主题是痛惜三个月的心血，抱怨客户的认知能力和欣赏水平。为了不让同办公室的人发现这件事，在沉默的一个小时我一直在佯装翻书，我随机地拿起桌旁的《Microsoft.net Compact Framework Core reference》，幸运的是我翻到了这样一页：
One of the most important features of any application, and particularly an application intended to run on a mobile device, is the look and feel of its user interface. No matter how effective or well designed your application is, if you do not provide an interface that is easy to interact with, people are unlikely to use the application.When designing a user interface, you need to bear in mind the differences between the devices that it might be displayed on. Mobile devices are not simply miniature PCs and cannot be treated as such. You must remember that as well as having a smaller viewable area, mobile devices can often display only a limited number of colors. You should ensure that you design your applications to make the best use of available screen real estate……
这句朴素到让你读这本书的第一遍时通常将其忽略的一句话“无论应用程序如何有效或设计得多么巧妙，如果没有提供一个易于交互和使用的界面，人们都是不会喜欢使用它的”是至关重要的。让我又一次听到客户刚才扔下的那句话的后半句“…，如果不能改变的话”。这与先前的沮丧不一样，因为是希望。“是啊，apan，现在你该做的是寻找如何改变的方法，你的功能设计是没有什么大的问题的，因为先前在你们曾经做过大量的需求分析并得到客户的许可，你的问题也许出在，应该是，肯定是出在GUI上，出在用户的交互和使用的界面上”，我对自己说。……开始行动。中午1点，下午4点，晚上10点，凌晨1点，2点，5点，直到早晨9点我约好了负责人……
2006年3月14日。将阅读方式更改后，我们与客户负责人做的第二次沟通。我成功了，尽管成功得的有点勉强。这一次的教训使我在两方面有了认识：一是客户第一，尊重客户的需求；二是善于有效地交流，不要一味埋头苦干和过分自恋。
一个白天加上一个晚上。我们经过仔细分析，站在客户的立场，充分考虑他们之所需，按照客户的要求重新进行的GUI设计分析，并以最快的速度搭建了一个尽可能接近传统纸版浏览方法的界面，部署到了样机上。他们接受了。如果没有这件事，我会一直坚持最初的设计，因为我觉得那是合理的，优秀的。然而客户先前的不满意是有理由、有依据的，并且是真实的，至关重要的。创新需要大胆，但创新也需要细心、科学，还有一点容易忽视的就是，洗牌是需要时间和过程的。
2006年3月19日。今晨5点出发去南开找导师做毕业论文设计指导，但是导师没在。就旁听了其他班的论文指导。指导会上，我讲述了自己的经历，并且得到了友善的支持和忠告，而且有几个老师也讲了他们遇到的一样的经历。在交流的过程中，我又有了新的认识：用户是需要引导的，一个项目的生命周期中，随着用户对系统的熟悉，他们会主动提出新的需求和设计，但是一开始他并一定不会接受至少在你认为是先进并合理的设计。
原先的初衷把自己在项目中遇到GUI设计问题结合他人的优秀文章，综述一篇关于GUI设计的技术讨论文章（其实我没有完整地看完过一本有关GUI设计的书籍），然而我却发现有许多优秀的文章所优秀的亮点在于原则而非教条和具体方法，因为没有哪一套设计的具体操作会真正适合你，它们都需要具体对待，比如GUI Bloopers by Jeff Johnson的许多原则都值得我们去体会，我的这个故事恰恰与如下几下观点相吻合：
- Focus on the users and their tasks, not the technology
- Don't complicate the users' task
- Design for responsiveness
- Try it out on users, then fix it!
结语：于是我开始相信《富爸爸》里说的那句话：成功是个贫乏的教师。因为失败尽管让我经历了一段难熬的时间，但他使我眼前一亮，那是我们在重复一些真知灼见的道理时的实际资本和宝贵财富。
CardViewer系列之准备篇--资源下载推荐 本系列文章目录 下一篇
如果您还没有阅读本系列开篇《CardViewer项目体会系列文章》，建议花些时间了解一下。
大堆废话：五年前学VB时常去一些论坛，获益不小。可有一次读了一个帖子的回复后我去的就少了，它是这样说的：“你们提的这些个问题，回去读一读MSDN的话就都解决了。”可想而知，它的后面跟的全是鸡蛋和番茄，当时的人民都很团结，因为这句话挑衅了他们的“民族”自尊心。这份回帖有些绝对，但是告诉我们一个有关学习方法的问题。于是我试着去做，一旦遇到了问题，就去看MSDN，往往都能找到答案，如果实在找不到，才去论坛求助，这样的问题往往在讨论时更有价值。欲速则不达。我曾经有过这样的学习方法：发现好的技术->google入门文章->模仿并code->发现问题->论坛求助->解决问题->code->发现问题->......循环之。表面上我好象是很快掌握新技术了，然而认知的一知半解，结果是：即使今天解决，下次遇到类似的问题你可能会觉得这是一个全新的问题。打个比方，没有学过加法的孩童，今天你告诉他1+2=3，他记住了，下次你问他2+1，他不一定会知道。然而有了加法的基础和训练，他就会计算更多的加法了。
磨刀不误砍柴功。完成项目之前，除了最重要的需求分析和系统设计之外，把你即将使用的工具系统和概况地了解以后再去code，只为提高效率。（这话是对和我一样的初学者说的，各位高手和前辈请不要扔我鸡蛋）
资源介绍：完成CardViewer，我们使用了很多资源，这里共享常用。
- Books: 开发之前我有重点的通读了几本书籍，这使我对项目中的需求有了足够的信心，并确定我将要重视的知识点。教材是不会完全解决你的问题，但它会告诉你这个问题是否可以解决、解决的线索以及成本等。这是我主要使用的三本入门教材。
- Beginning.Visual.C.Sharp：如果你是一个C#和.net新手，这本书值得一读，尤其是事件和属性的讲解是这本书的亮点。
- Microsoft.NET Compact Framework Core reference：个人认为这是开发mobile的必读书，应该这此类书籍少之又少，读过几本中文的mobile书籍，好象都不够切题，讨论的问题比较分散。
- Professional C# 3rd Edition：C#入门的补充，讨论了更多高级问题。由于.netCF的编程与.net的方法基本都是一样的，主要还是library不同，所以这本书的知识完全可以应用的mobile编程里去。
- MSDN: 教材不是字典，想查字典就看MSDN（本地和在线的）。目前我所遇到的大部分问题，基本上都可以在本地的MSDN里找到答案，尽管这需要耐心和十分的耐心。
- Link:
CardViewer系列之准备篇--J2ME vs .netCF 本系列文章目录 下一篇