Oracle神谕

1.业务建模(需求)  架构
2.技术架构            总体把握
3.数据库设计        提升
4.PM 能力             文档

14 Key Principles for PM Success This web-published article by Michael Greer is an excerpt from "Chapter 6: Planning and Managing Human Performance Technology Projects," Handbook of Human Performance Technology, San Francisco, Jossey-Bass, 1999

来源地：http://www.cpmi.org.cn/cn/asp/news.asp?articleid=1840&classid=24&nclassid=0

1. Project managers must focus on three dimensions of project success. Simply put, project success means completing all project deliverables on time, within budget, and to a level of quality that is acceptable to sponsors and stakeholders. The project manager must keep the team''s attention focused on achieving these broad goals.  2. Planning is everything -- and ongoing. On one thing all PM texts and authorities agree: The single most important activity that project managers engage in is planning -- detailed, systematic, team-involved plans are the only foundation for project success. And when real-world events conspire to change the plan, project managers must make a new one to reflect the changes. So planning and replanning must be a way of life for project managers.  3. Project managers must feel, and transmit to their team members, a sense of urgency. Because projects are finite endeavors with limited time, money, and other resources available, they must be kept moving toward completion. Since most team members have lots of other priorities, it''s up to the project manager to keep their attention on project deliverables and deadlines. Regular status checks, meetings, and reminders are essential.  4. Successful projects use a time-tested, proven project life cycle. We know what works. Models such as the standard ISD model and others described in this text can help ensure that professional standards and best practices are built into our project plans. Not only do these models typically support quality, they help to minimize rework. So when time or budget pressures seem to encourage taking short cuts, it''s up to the project manager to identify and defend the best project life cycle for the job.  5. All project deliverables and all project activities must be visualized and communicated in vivid detail. In short, the project manager and project team must early on create a tangible picture of the finished deliverables in the minds of everyone involved so that all effort is focused in the same direction. Avoid vague descriptions at all costs; spell it out, picture it, prototype it, and make sure everyone agrees to it.  6. Deliverables must evolve gradually, in successive approximations. It simply costs too much and risks too much time spent in rework to jump in with both feet and begin building all project deliverables. Build a little at a time, obtain incremental reviews and approvals, and maintain a controlled evolution.  7. Projects require clear approvals and sign-off by sponsors. Clear approval points, accompanied by formal sign-off by sponsors, SMEs, and other key stakeholders, should be demarcation points in the evolution of project deliverables. It''s this simple: anyone who has the power to reject or to demand revision of deliverables after they are complete must be required to examine and approve them as they are being built.  8. Project success is correlated with thorough analyses of the need for project deliverables. Our research has shown that when a project results in deliverables that are designed to meet a thoroughly documented need, then there is a greater likelihood of project success. So managers should insist that there is a documented business need for the project before they agree to consume organizational resources in completing it.  9. Project managers must fight for time to do things right. In our work with project managers we often hear this complaint: "We always seem to have time to do the project over; I just wish we had taken the time to do it right in the first place!" Projects must have available enough time to "do it right the first time." And project managers must fight for this time by demonstrating to sponsors and top managers why it''s necessary and how time spent will result in quality deliverables.  10. Project manager responsibility must be matched by equivalent authority. It''s not enough to be held responsible for project outcomes; project managers must ask for and obtain enough authority to execute their responsibilities. Specifically, managers must have the authority to acquire and coordinate resources, request and receive SME cooperation, and make appropriate, binding decisions which have an impact on the success of the project.  11. Project sponsors and stakeholders must be active participants, not passive customers. Most project sponsors and stakeholders rightfully demand the authority to approve project deliverables, either wholly or in part. Along with this authority comes the responsibility to be an active participant in the early stages of the project (helping to define deliverables), to complete reviews of interim deliverables in a timely fashion (keeping the project moving), and to help expedite the project manager''s access to SMEs, members of the target audience, and essential documentation.  12. Projects typically must be sold, and resold. There are times when the project manager must function as salesperson to maintain the commitment of stakeholders and sponsors. With project plans in hand, project managers may need to periodically remind people about the business need that is being met and that their contributions are essential to help meet this need.  13. Project managers should acquire the best people they can and then do whatever it takes to keep the garbage out of their way. By acquiring the best people -- the most skilled, the most experienced, the best qualified -- the project manager can often compensate for too little time or money or other project constraints. Project managers should serve as an advocate for these valuable team members, helping to protect them from outside interruptions and helping them acquire the tools and working conditions necessary to apply their talents.  14. Top management must actively set priorities. In today''s leaner, self-managing organizations, it is not uncommon for project team members to be expected to play active roles on many project teams at the same time. Ultimately, there comes a time when resources are stretched to their limits and there are simply too many projects to be completed successfully. In response, some organizations have established a Project Office comprised of top managers from all departments to act as a clearinghouse for projects and project requests. The Project Office reviews the organization''s overall mission and strategies, establishes criteria for project selection and funding, monitors resource workloads, and determines which projects are of high enough priority to be approved. In this way top management provides the leadership necessary to prevent multi-project log jams.

Features and Contents of Control File
Is a binary file that is necessary for the database to start and operate successfully.
Every time an instance mounts an Oracle database, it reads the control file to locate the data files and online redo log files.
Is updated continuously during database use and must be available whenever the database is mounted or opened.
Provides information about database consistency used during recovery.
If any of the control files currently being used by the database becomes unavailable , then the database cannot function properly.
In summary, control file contains the following information
--Database name
--Data file location
--Redo log file location
--Tablespace names
--Current log sequence number
--Checkpoint information
--Log history
--Backup information

////////////////////////////
Tablespaces
A tablespace can belong to only one database.
Each tablespace consists of one or more operating stystem files.
Tablespaces can be brought online while the database is running.
Except for the SYSTEM tablespace or a tablespace with an active rollback segment, tablespaces can be taken offline, leaving the database running.
Tablespaces can be swtiched between read-write and read-only status.
Controlling space allocation and assigning space quotas to users.
Controlling availability of data by taking individual tablespaces online or offline
Distributing data storage across devices to improve I/O performance and to reduce I/O contention agsinst a single disk.
Performing partial backup and partial recovery operations.
Keeping large amounts of static data on read-only devices.

///////////////////////////
Data Files
Each tablespace in a Oracle consists of one or more files called data files. These are physical structures that conform with the operating system on which the Oracle Server us running.
An Oracle server creates a data file for a tablespace by allocating the specified amount of disk space plus a small overhead.
The database administrator can change the size of a data file after its creation or can specify that a data file should dynamically grow as objects in the tablespace grow.
/////////////////////////////////////
Segment
A segment is the space allocated for a specific type of logical storage structure within a tablespace. The following are example of segments:
--Table segment
--Index segment
--Temporary segment
--Rollback segment
A segment such as a data segment may span multiple files that belong to the same tablespace.

/////////////////////////////////////
Extents
An extends is a set contiguous number of blocks.
Each type of segment is made up of one or more extents.
An extent may not span a data file, but muts exist in one data file.

/////////////////////////////////////////////////////
Data Blocks
At the finest level of granularity , the data in an Oracle database is stored in data blocks.
One data block corresponds to one or more physical file blocks allocated from an existing data file.
Data block size is specified for each Oracle database by the initialization parameter DB_BLOCK_SIZE when the database is created.
The samllest unit of input-output.

//////////////////////////////////////////////////////

SYSTEM and Non-SYSTEM Tablespaces
SYSTEM Tablespace
Automatic created after the database is created
Required in all databases for database operation.
Contains data dictionary information, definitions of stored procedures, packages, and database triggers.
Contains the SYSTEM rollback segment.
Should not contain use data although it is allowed.

Non-SYSTEM Tablespace
Enable more flexibility in database administration
Can store rollback segments,temporary segments, application data, and application indexes.

CREATE TABLESPACE app_data
DATAFILE '/DISK4/app01.dbf' SIZE 100M,
         '/DISK5/app02.dbf' SIZE 100M
MINIMUM EXTENT 500K
DEFUALT STORAGE(INITIAL 500K
                NEXT    500K
                MINEXTENTS 3
                MAXEXTENTS 500
                PCTINCREASE 50);

Method 1: Adding Data Files to a Tablespace
ALTER TABLESPACE app_data ADD DATAFILE
 '/DISK5/app03.dbf' SIZE 200M;
 

Method 2: Enabling Automatic Extension of new created Data Files
ALTER TABLESPACE app_data ADD DATAFILE
'/DISK6/app04.dbf'  SIZE 200M
AUTOEXTEND ON NEXT 10M MAXSIZE 500M;
              
Method 3: Enabling Automatic Extension of existing Data Files
ALTER DATABASE
DATAFILE '/DISK5/app03.dbf'
AUTOEXTEND ON NEXT 10M MAXSIZE 500M;

Method 4:Changing the Size of Data Files Manually
ALTER DATABASE DATAFILE '/DISK5/app02.dbf'
RESIZE 200M;

READ-ONLY tablespace
Making tablespaces read-only prevents further write operations on the data files. The purpose of read-only tablespaces is to ensure that on changes are made and to eliminate the need to perform backup and recovery of large, static portions of a database. The Oracle server never updates the files of a read-only tablespace, and therefore the files can reside on read-only media, such as CD ROMs or WORM drives.

Making tablespace APP_DATA only available for read operations.
ALTER TABLESPACE app_data READ ONLY;

DBA_TABLESPACES

/////////////////////////////////////////////////////
Storage Structure and Relationships

 

select a.segment_name,a.tablespace_name,a.extents,a.blocks
 from dba_segments a
 where owner='TPL'
 
 
 select a.extent_id,a.file_id,a.block_id,a.blocks from dba_extents a where owner='TPL'
 
 
select tablespace_name  ,count(*),max(blocks),sum(blocks)
from dba_free_space
group by tablespace_name

//////////////////////////////////////
Rollback Segment
Purpose of Rollback Segment

Transaction Rollback

When a transaction makes changes to a row in a table, the old image is saved in the rollback segment. If the transaction is rolled back, the value in the rollback segment is written back to the row, restoring the original value.

Read Consistency
When transactions are in progress, other users in the database should not see any uncommitted changes made by these transactions. In addition, a statement should not see any changes that were committed after the statement commences execution. The old values in the rollback segments are also used to provide the readers a consistent image for a given statement.

Transaction Recovery
If the instance  fails when transactions are in progress, Oracle server needs to rollback the uncommitted changes when the database is opened again. This rollback is known as transaction recovery and is only possible if changes made to the rollback segment are also protected  by the redo log files.

/////////////////////////////////////////
How transactions use Rollback Segment
1.When a transaction begins, a rollback segment needs to be assigned to this transaction.
2.A transaction may request a specific rollback segment using the following command:
  SET TRANSACTION USE ROLLBACK SEGMENT rollback_segment
3.If no such request is made, the Oracle server chooses the rollback segment with the fewest transactions, and assigns it to the transaction.
4.Transactions use extends of a rollback segment in an ordered circular fashion, moving from one to the next after the current extent is full.
5.The pointer or the head of the rollback segment moves to the next extent when the current extet is full.
6.The OPTIMAL parameter specifies the size in bytes that a rollback segment must shrink to, if possible. Specifying OPTIMAL minimizes the waste of space in a rollback segment. If the OPTIMAL parameter is specified, a rollback segment can release space on completion of transactions that caused the growth.

create rollback segment rbs01
tablespace USERS
storage (initial 100k
         next    100k
         optimal 4M
         minextents 20
         maxextents 100);

alter rollback segment rsb01 online;

alter rollback segment rsb01 offline;

drop rollback segment rsb01;

select a.USN,a.EXTENTS,a.OPTSIZE,a.HWMSIZE,a.XACTS,a.STATUS from v$rollstat a

//////////////////////////////////////////////////
Temporary Segment
Temporary segment are used when statement such as the following are executed and the Oracle server cannot perform the sorting needed in memory because it is bigger that SORT_AREA_SIZE.
--SELECT ...ORDER BY
--CREATE INDEX
--SELECT DISTINCT
--SELECT...GROUP BY
The amount of memory used by a process for sorting  is determined by the SORT_AREA_SIZE initialization parameter. If the sort volume exceeds this size, serveral sort runs are needed, and intermedidate results are stored on disk.
Temporary segments are created and used by the Oracle server in the tablespace that has been assigned to the user for sorting.

Temporary Segments in a Temporary Tablespace
Known as sort segments
Only one segment per tablespace per instance
Created when the first disk sort occurs in the instance after startup
Reused by serveral transactions based on information in the SORT Extent Pool
Release on instance shutdown.

select *from v$sort_segment

select * from v$sort_usage

///////////////////////////////////
Managing Indexes

B-Tree Index
////////////////////////////////////////////////////////////

     几个月没有提笔了，似乎这个BLOG快到收笔的时候了。最近几个月总是感觉忙忙碌碌的。代码写的少了，技术相关的东西也很少有时间去琢磨，更多的时间在流程的把握、客户的沟通、系统部署、进度的控制。这个过程确实也很让人痛苦。今天在走廊碰到隔壁的仁兄，他所偶的白头发又多了。
     感觉最近确实各方面都是很理想。忙忙碌碌的总有处理不完的事情。振奋人心的事情越发的少。
     调整自己，迷茫中尽快找到自己，迷失自己，将很难有所成就！

    还在深夜，窗外昆虫还是"唧唧"地叫着，楼上的吵架声音将人从睡梦中吵醒。现在是凌晨近4点种。虽然睡意朦胧，但脑子还是清楚的。
    许久没有写些东西了。特别是技术上的东西。最近又捡起了Delphi，写一些小程序。虽然只是辅助性质的，还是耗费了一些时间和精力。
     也许是自己转型期，更加注重管理层面东西。然技术是立足之本，有时间还是要钻研一些东西的。

那一天
我不得已上路
为不安分的心
为自尊的生存
为自我的证明
路上的辛酸已融进我的眼睛
心灵的困境已化作我的坚定

在路上 用我心灵的呼声
在路上 只为伴着我的人
在路上 是我生命的远行
在路上 只为温暖我的人
温暖我的人

那一天
我得以已上路
为不安分的心
为自尊的生存
为自我的证明
路上的辛酸已融进我的眼睛
心灵的困境已化作我的坚定

在路上  用我心灵的呼声
在路上 只为伴着我的人
在路上 是我生命的远行
在路上 只为温暖我的人
温暖我的人

在路上 用我心灵的呼声
在路上 只为伴着我的人
在路上 是我生命的运行
在路上 只为温暖我的人
温暖我的人

     窗外下着小雨，心情也一样湿漉漉的。快要国庆了，时间过得很快，一年的时间有一大半已经过去了。回想今年事情，时而感觉斗志昂扬，时而情绪低落。在波峰波谷之间徘徊。页面常常出现的设计的软件的界面东东，飞来飞去。也许是属于成功与失败的交错期间，心情也很奇怪。手中还有很多的事情要做处理。感觉这一阵有些乱，本来自己要求要写的工作日志有半个多月没有写了。也很难精心去写一个功能。僵化了的思想。
     感觉自己能力也有限，很多事情心有余而力不足。软件从可行性到设计、分析到开发实现，直到部署过去，有不少的环节要注意。要每个环节都要做充分的重视。销售，客户的想法，这些东西有时间真的很难处理。软件是复杂的，要满足客户的需求、市场的需求、销售人员的、实施人员的需求，很多很多细节要进行考虑，而且很多考虑的还是非功能性的问题。在固定的时间固定的成本来完成一定的项目，是一个项目管理者一个很重要的素质，也是成功者说必须具体的东西。但是现实就是这么残酷，人员的沟通、技术的成熟度、产品的定义，不要有太多的牢骚，其实只需要你实干，针对事情有很好的解决就可以了。另外文档化，不要忘记你需要进行的处理。当然，对于我们来说还有个优先度的问题。问题出现了，要勇于去承担这个责任，躲避是没有办法躲避的。
    国庆！举国同庆。但是真正能开心的、放松心情的又有几个呢。有时候想想还是做一个普通开发人员多好，只要解决技术问题，其他的都可以放到一边去。
   也许真的需要去放松一下心情。找朋友在一起聚聚，喝喝酒了。
   前面的路还很长，软件还要继续做下去。未来的很多事情都还要做处理的。

        有好一阵没有写BLOG了，感觉手生疏了许多。面临即将入秋的天气，心情也有点凉凉的。昨晚睡早了些，今天居然5点多就爬了起来。晚上老是做梦，奇怪的梦让我老是睡眠不好。前一阵咽炎，吃了大小包N多药片、颗粒，现在总算好了些。有一阵没有抽烟了，感觉还是不抽烟的日子好一些。
       最近感觉很是失败，似乎也没有什么能提起神的东西。儿子也在家里，听说现在都可以在学步车上跑来跑去，想来一定很可爱的。想起我的儿子，不仅有些神伤。最近一起工作了一年多的一个同事要离开了，说是在的，大家能一直坚持到现在却是很不容易。但是客观的情况确实不容乐观。前途堪忧啊。
      有一阵没有实际去写代码了，手也有些生了。现在主要在看一些软件项目管理的书。

     这一阵在与客户的接触中，越来越感觉自己做这个行业的特殊性。软件，“软”而不硬，没有刚性。在《高级汉语词典》中软，质地不硬，与“硬”相对。说来有很是有意思，做软件也有5、6年了，一只对这个东西没有很明确的认识。直到去拜见客户的财务科长，对方曰“软件不是劳务，干完就给钱，这个需要........”。
    软件的软体现在如下几个方面:
（1）需求的不确定性，或者说需求的扩充性。就国内的软件服务商与客户大都签合同在前，做需求调研的在后，当然也有干脆不做调研的，当然项目最终肯定是失败的。需求的增加，或者随着软件的使用，客户对需求或者说对软件的要求不断增强，这就决定了软件本身的“软”。
（2）软件的使用者的软性。不同的软件使用者其对软件的要求也不相同，个人的操作习惯等等，都决定软件必须灵活多变，似乎像是孙悟空一样，拥有“72变”；
（3）软件交付与付款的“软”。做为软件交付时，验收的标准很难进行统一。软件使用者的认为软件是“万能的”，存在一点点的小问题，也会把它作为拒绝付款的理由。这中间，有主动权的把握和客户关系的把握之间的平衡。对软件不断更新，软件成本增加，客户提出的若干问题，来者不拒，结果项目迟迟不能close，客户关系自然好了，但是问题也出来，款也未必过来；如果一定在付款占据主动，更新推迟，但对客户的关系不利。两者如何平衡，确实有很大的学问。

Dojo的设计哲学

Understanding Your Own Footprint
理解你自己的足迹
Every useful system carries the imprint of its designers. From bridges to spoons, the expression of a builder's skill, philosophies, and production constraints are exposed in the final product. Software is no different, except in its propensity to change. Software mutates in response to users needs, and in that change, a continual re-impriting of a designer's skill and sense of taste takes place.
每一个有用的系统留下它的设计师的烙印。从桥梁到勺子，一个建造者技巧的表达，哲学家，和产品约束在最终的产品中被暴露。软件是不同的，除了它的变化的倾向。在用户需要的反应中的软件变异，和在那种改变中，一个连续的重复的不可能的一个设计师的技巧和味觉产生。
This has the potential to cause continuity problems for others, be they end users or other developers. Reducing these confusing aspects (cognitive load) allows software consumers of every type to feel better about a block of code. With every interaction, their pre-conceived notions of how the thing will behave serve them instead of forming an obstacle for them to overcome. Their instincts are turned into a valuable tool by elegantly and consistently designed software.
这是为其他产生持续问题的本质，是他们最终用户或其他开发者。减少这些混乱的方面（认知的负荷）允许每一种类型的软件消费者感觉更好关于一些代码。伴随每一次交互，他们的预设想的概念是这些东西如何运转服务他们而不是组成一个为他们跨越的障碍。他们的本能是通过优美和一贯地设计的软件变成一个有价值的工具。
Dojo, as a project, should meet expectations in this way. This doesn't mean that you have to agree with every design decision that's been made in the project (dissent is healthy) or that the guiding principles outlined here are written in stone. They should, however, capture the way design choices have been made to date and serve as a guide for making future decisions.
     Dojo，作为一个项目，应该满足这样的期望。这不意味这你不得不同意每一个设计决定，即它已经向项目中进入（不同意是健康的）或者那写入石头中的导向原理轮廓。他们应该是，然而，捕捉设计选择的方法已经提到日程和作为未来决定的向导。

Dojo Guiding Principles
Dojo的设计导向原则
Reduce barriers to adoption.
采用减少障碍物。
Simply put, do not give users reasons not to choose your code. This affects everything from design to licensing to packaging.
简单放置，但是不给用户不使用你代码的原因。这影响从设计到专利的包装的每件事情。
Simple first, fast later
简单优先，快在后
Make it simple to use first, make it fast when it's approprite. Simple here means simple for users, not for us. We should work as hard as necessary to make things simple for end users. This principle goes to reducing barriers to adoption. Things should be as easy as possible for the common case but transparently "upgradeable" to a faster code path if the end user is willing to learn about the performance dials and knobs.
首要的简单使用，当它是适合的将它打上结。 简单这里意味这对用户简单，不是对我们。我们应该使工作对最终用户尽可能的变得简单。这些原则定位在采用减少障碍的原则。事情应该尽可能容易对共同的情形但是明显“可升级的”对一个快速的代码路径 如果终端用户想要了解执行的表盘和旋钮。
Bend to the constraints of your environment
混合你环境的约束
Do not bludgeon a problem to death with code. If the environment can do most of something, let it. Fill in as necessary, but do not re-invent. Make the path smooth for users, but do not introduce your own idioms where they aren't required.
不要棒击一个问题来伴随代码死亡。如果这个环境可以做大部分是事情，让它做。尽可能替代，不要重新发明。对用户来说将路径平滑，当他们不需要的地方不要介绍你自己的方言。

Improving From Here
从这里改进
Dojo may not yet completely embody the principles outlined here, but it is their purpose to serve as a guide for the project when making determinations how things should change.
Dojo可能没有完全包含这里轮廓的原则，但它是当描述这些事情应该如何改变,他们作为一个向导对项目来服务的目的。
If you think that Dojo has not yet met one or more of these goals in a particular way, please raise the issue on one of the project mailing lists or file a bug.
如果你认为Dojo还没有满足在特定方法中的一个或多个这些目标，请提出一个issue在一个项目邮件列表或文件作为一个bug。