巧遇老同事

今天中午吃完饭在公司楼下闲聊的时候,有个人走到我面前说:“还记得我吗?”。我记性很差的,认人的能力也不行,不过一看到他我马上说出了他的名字,真没想到在这里能遇到他。说来也奇怪,上周五在回家的路上我还忽然想起他,不知道他最近混得怎么样。

我们俩原来在同一家公司干过几个月,当时在同一个项目小组里搞开发,后来由于各自的原因先后离开,时间一久就断了联系,到现在有两三年没见面了。其实我对他了解的也不多,但在我看来他是个很淳朴的人,不仅外表看起来忠厚老实,讲起话来也不急不躁,很平和,完全没有“社会上”的感觉,今天和他聊了一会儿竟然觉得心里一丝安慰。

他现在发展得很不错,在这里工作两年,工资已经是那时的好几倍了,他说:“这已经是我第五个工作了!”,看得出他对目前的状况很满意,他还说不打算再跳了。我也挺替他感到高兴的,不过想想自己,同样的年龄,却还处于艰苦的学习和积累经验阶段,即将面对的社会充满竞争和变数,一年后我能追上他吗,两年?

最后我们互留了MSN,我看到他的昵称是”Working is beautiful”。

Plugin.xml -> Manifest.mf

为了更好的实现动态加载/卸载插件,Eclipse从3.0开始实现OSGI规范,原先在plugin.xml文件里定义的很多内容都被推荐放在manifest.mf文件里,只有<extension>和<extension-point>是例外。下面是两种文件格式中各元素的对照表:

plugin.xml tag/attribute
manifest.mf header
<plugin id=> Bundle-SymbolicName
<plugin version=> Bundle-Version
<plugin name=> Bundle-Name
<plugin provider=> Bundle-Vendor
<plugin class=> Bundle-Activator
<fragment plugin-id=> Fragment-Host
<fragment plugin-version=> Fragment-Host: <id>; bundle-version=
<requires>, <import> Require-Bundle
<runtime>, <library> Bundle-ClassPath

具体的转换方法在这里可以看到,也就是说,我们在Eclipse 3.0以上版本中开发插件的时候,最好使用manifest.mf文件的方式(实际上Eclipse自带的Plugin Manifest Editor在这方面已经帮我们做了不少工作,新版本的Eclipse在创建新项目时会自动把可以放在manifest.mf文件中的内容转移过去)。

让我试试”eRCP”

我对掌上电脑有兴趣已经好几年了,不过到现在都没能拥有一台实物,毕竟价格挺高的,而且也不是缺它不可的情况。今天在Eclipse网站上下载了一个eRCP,这好象是去年底开始的新项目,是Eclipse RCP向嵌入式应用的发展,相当于对RCP中各个组成部分的精简实现,因为那些设备对应用程序的大小十分敏感。

由于以前没有实际做过这方面的开发,对掌上电脑的使用也不了解,所以让eRCP自带的例子在模拟器上运行起来还花了些功夫,主要是环境麻烦点,这里记下来以免下次忘记,有一些链接我感觉还是比较有用的。

首先从eclipse.org/ercp下载eRCP程序包,它是一个只有4M多的.zip文件,打开一看里面包含了x86(即我们大部分人用的PC机)、wm2003(MS Windows Mobile 2003)和series80(Symbian OS series80)这三种环境的支持,其中前二者的每一个文件夹的结构都和标准RCP应用程序差不多,在eRCP目录下是startup.jar和一个链接文件,然后有plugins和configuration目录;后者这种操作系统我不熟悉,目录里包含的主要是两个.sis文件。

在每个版本里都包含了一个很简单的例子,我先在电脑上试了一下x86版本,因为机器上已经装有jre,所以只要系统path变量里有java.exe所在路径,直接运行j2se.bat即可。(这里还有点问题,在公司的电脑上一切正常,但在我笔记本上提示“An unexpected exception has been detected in native code outside the VM.”,原因未知。)

因为没有掌上电脑,所以要下载一个模拟器,其实搞开发用模拟器应该比较方便。想起前几天在Hi!PDA上看到微软新出了一个wm2003模拟器(查看原贴,下载地址在这里),这回正好用来当环境!还要下载一个ActiveSync软件用来同步和控制PocketPC,同步这个模拟器的方法在原贴里已经有人提到,这里就不重复了,后面一些步骤须要把电脑里的文件复制到PocketPC上就可以利用ActiveSync的Explorer功能。

然后要下载一个PocketPC上的java环境,比较常用的是IBM的j9虚拟机,下载地址在这里(需要登录),下载页面会有很多个文件,不过只下载名称以“weme-wm2003-arm-ppro10”开头(Personal Profile)的那个.exe或.bin文件就够了。在电脑上运行这个程序,会得到一个jre以及一些.cab文件,把名为weme-ppro10-wm2003-arm_22.cab的文件(在我的电脑上该文件位于“C:\Program Files\IBM\WEME\572\WM2003\arm\PPro10\cab”目录)复制到PocketPC上运行,就会在PocketPC上安装java运行环境了。

现在要把eRCP程序包里wm2003那部分复制到PocketPC的根目录,注意要复制的目录从eRCP开始,即复制后在PocketPC上形成\eRCP目录,如下图所示。

图1 从电脑里把wm2003下的eRCP目录复制到\下

不过现在还不能直接点j9foun链接,因为我们在PocketPC上安装的是j9ppro,链接里的路径和参数都是无效的。解决方法是新建(或修改它为)一个链接把原来内容里的两处foun都改为ppro,修改后如下:

37#”\Program Files\J9\PPRO10\bin\j9.exe” -jcl:ppro10 -cp \eRCP\startup.jar org.eclipse.core.launcher.Main -application org.eclipse.ercp.example.ercpHello.ercpHello -console

假设新的链接名为j9ppro,这时就可以点它运行eRCP例子程序了。执行画面如下图所示。我感觉在模拟器上运行速度慢了许多,不知道在真机上效果会是怎样的,应该会有所提高,毕竟执行速度对PocketPC上的应用来说是至关重要的。

图2 eRCP例子在PocketPC上运行效果

[Eclipse]GEF入门系列(十一、树的一个实现)

两天前GEF发布了3.1M7版本,但使用下来发现和M6没有什么区别,是不是主要为了和Eclipse版本相配套?希望3.1正式版早日发布,应该会新增不少内容。上一篇帖子介绍了如何实现表格功能,在开发过程中,另一个经常用到的功能就是树,虽然SWT提供了标准的树控件,但使用它完成如组织结构图这样的应用还是不够直观和方便。在目前版本(3.1M7)的GEF中虽然没有直接支持树的实现,但Draw2D提供的例子程序里却有我们可以利用的代码(org.eclipse.draw2d.examples.tree.TreeExample,运行界面见下图),通过它可以节约不少工作量。

图1 Draw2D例子中的TreeExample

记得数年前曾用Swing做过一个组织结构图的编辑工具,当时的实现方式是让画布使用XYLayout,在适当的时候计算和刷新每个树节点的位置,算法的思想则是深度优先搜索,非树叶节点的位置由其子节点的数目和位置决定。我想这应该是比较直观的方法吧,但是这次看了Draw2D例子里的实现觉得也很有道理,以前没想到过。在这个例子里树节点图形称为TreeBranch,它包含一个PageNode(表现为带有折角的矩形)和一个透明容器contentsPane,(一个Layer,用来放置子节点)。在一般情况下,TreeBranch本身使用名为NormalLayout的布局管理器将PageNode放在子节点的正上方,而contentsPane则使用名为TreeLayout的布局管理器计算每个子节点应在的位置。所以我们看到的整个树实际上是由很多层子树叠加而成的,任何一个非叶节点对应的图形的尺寸都等于以它为根节点的子树所占区域的大小。

从这个例子里我们还看到,用户可以选择使用横向或纵向组织树(见图2),可以压缩各节点之间的空隙,每个节点可以横向或纵向排列子节点,还可以展开或收起子节点,等等,这为我们实现一个方便好用的树编辑器提供了良好的基础(视图部分的工作大大简化了)。

图2 纵向组织的树

这里要插一句,Draw2D例子中提供的这些类的具体内容我没有仔细研究,相当于把它们当作Draw2D API的一部分来用了(包括TreeRoot、TreeBranch、TreeLayout、BranchLayout、NormalLayout、HangingLayout、PageNode等几个类,把代码拷到你的项目中即可使用),因为按照GEF 3.1的计划表,它们很有可能以某种形式出现在正式版的GEF 3.1里。下面介绍一下我是如何把它们转换为GEF应用程序的视图部分从而实现树编辑器的。

首先从模型部分开始。因为树是由一个个节点构成的,所以模型中最主要的就是节点类(我称为TreeNode),它和例子里的TreeBranch图形相对应,它应该至少包含nodes(子节点列表)和text(显示文本)这两个属性;例子里有一个TreeRoot是TreeBranch的子类,用来表示根节点,在TreeRoot里多了一些属性,如horizontal、majorSpacing等等用来控制整个树的外观,所以模型里也应该有一个继承TreeNode的子类,而实际上这个类就应该是编辑器的contents,它对应的图形TreeRoot也就是一般GEF应用程序里的画布,这个地方要想想清楚。同时,虽然看起来节点间有线连接,但这里我们并不需要Connection对象,这些线是由布局管理器绘制的,毕竟我们并不需要手动改变线的走向。所以,模型部分就是这么简单,当然别忘了要实现通知机制,下面看看都有哪些EditPart。

与模型相对应,我们有TreeNodePart和TreeRootPart,后者和前者之间也是继承关系。在getContentPane()方法里,要返回TreeBranch图形所包含的contentsPane部分;在getModelChildren()方法里,要返回TreeNode的nodes属性;在createFigure()方法里,TreeNodePart应返回TreeBranch实例,而TreeRootPart要覆盖这个方法,返回TreeRoot实例;另外要注意在refreshVisuals()方法里,要把模型的当前属性正确反映到图形中,例如TreeNode里有反映节点当前是否展开的布尔变量expanded,则refreshVisuals()方法里一定要把这个属性的当前值赋给图形才可以。以下是TreeNodePart的部分代码:

public IFigure getContentPane() {
    return ((TreeBranch) getFigure()).getContentsPane();
}

protected List getModelChildren() {
    return ((TreeNode) getModel()).getNodes();
}

protected IFigure createFigure() {
    return new TreeBranch();
}

protected void createEditPolicies() {
    installEditPolicy(EditPolicy.COMPONENT_ROLE, new TreeNodeEditPolicy());
    installEditPolicy(EditPolicy.LAYOUT_ROLE, new TreeNodeLayoutEditPolicy());
    installEditPolicy(EditPolicy.SELECTION_FEEDBACK_ROLE, new ContainerHighlightEditPolicy());
}

上面代码中用到了几个EditPolicy,这里说一下它们各自的用途。实际上,从Role中已经可以看出来,TreeNodeEditPolicy是用来负责节点的删除,没有什么特别;TreeNodeLayoutEditPolicy则复杂一些,我把它实现为ConstrainedLayoutEditPolicy的一个子类,并实现createAddCommand()和getCreateCommand()方法,分别返回改变节点的父节点和创建新节点的命令,另外我让createChildEditPolicy()方法返回NonResizableEditPolicy的实例,并覆盖其createSelectionHandles()方法如下,以便在用户选中一个节点时用一个控制点表示选中状态,不用缺省边框的原因是,边框会将整个子树包住,不够美观,并且在多选的时候界面比较混乱。

protected List createSelectionHandles() {
    List list=new ArrayList();
    list.add(new ResizeHandle((GraphicalEditPart)getHost(), PositionConstants.NORTH));
    return list;
}

选中节点的效果如下图,我根据需要改变了树节点的显示(修改PageNode类):

图3 同时选中三个节点(Node2、Node3和Node8)

最后一个ContainerHighlightEditPolicy的唯一作用是当用户拖动节点到另一个节点区域中时,加亮显示后者,方便用户做出是否应该放开鼠标的选择。它是GraphicalEditPolicy的子类,部分代码如下,如果你看过Logic例子的话,应该不难发现这个类就是我从那里拿过来然后修改一下得到的。

protected void showHighlight() {
    ((TreeBranch) getContainerFigure()).setSelected(true);
}

public void eraseTargetFeedback(Request request) {
    ((TreeBranch) getContainerFigure()).setSelected(false);
}

好了,现在树编辑器应该已经能够工作了。为了让用户使用更方便,你可以实现展开/收起子节点、横向/纵向排列子节点等等功能,在视图部分Draw2D的例子代码已经内置了这些功能,你要做的就是给模型增加适当的属性。我这里的一个截图如下所示,其中Node1是收起状态,Node6纵向排列子节点(以节省横向空间)。

图4 树编辑器的运行界面

这个编辑器我花一天时间就完成了,但如果不是利用Draw2D的例子,相信至少要四至六天,而且缺陷会比较多,功能上也不会这么完善。我感觉在GEF中遇到没有实现过的功能前最好先找一找有没有可以利用的资源,比如GEF提供的几个例子就很好,当然首先要理解它们才谈得上利用。

 

[Eclipse]GEF入门系列(十、表格的一个实现)

在目前的GEF版本(3.1M6)里,可用的LayoutManager还不是很多,在新闻组里经常会看到要求增加更多布局的帖子,有人也提供了自己的实现,例如这个GridLayout,相当于SWT中GridLayout的Draw2D实现,等等。虽然可以肯定GEF的未来版本里会增加更多的布局供开发者使用(可能需要很长时间),然而目前要用GEF实现表格的操作还没有很直接的办法,这里说说我的做法,仅供参考。

实现表格的方法决定于模型的设计,初看来我们似乎应该有这些类:表格(Table)、行(Row)、列(Column)和单元格(Cell),每个模型对象对应一个EditPart,以及一个Figure,TablePart应该包含RowPart和ColumnPart,问题是RowFigure和ColumnFigure会产生交叉,想象一下你的表格该使用什么样的布局才能容纳它们?使用这样的模型并非不能实现(例如使用StackLayout),但我认为这样的模型需要做的额外工作会很多,所以我使用基于列的模型。

在我的表格模型里,只有三种对象:Table、Column和Cell,但Column有一个子类HeaderColumn表示第一列,同时Cell有一个子类HeaderCell表示位于第一列里的单元格,后面这两个类的作用主要是模拟实现对行的操作–把对行的操作都转换为对HeaderCell的操作。例如,创建一个新行转换为在第一列中增加一个新的单元格,当然在这同时我们要让程序给其余每一列同样增加一个单元格。

图1 表格编辑器

现在的问题就是怎样让用户察觉不到我们是在对单元格而不是对行操作。需要修改的地方有这么几处:一是创建新行或改变行位置时显示与行宽一致的插入提示线,二是在用户点击位于第一列中的单元格(HeaderCell)时显示为整个行被选中,三是允许用户通过鼠标拖动改变行高度,最后是在改变行所在位置或大小的时候显示正确的回显(Feedback)图形。下面依次介绍它们的实现方法。

调整插入线的宽度

在我们的调色板里有一个Row工具项,代表表格中的一个行,它的作用是创建新的行。注意这个工具项的名字虽然叫Row,实际上用它创建的是一个HeaderCell对象,创建它的代码如下:

tool = new CombinedTemplateCreationEntry(“Row”, “Create a new Row”, HeaderCell.class, new SimpleFactory(HeaderCell.class), CbmPlugin.getImageDescriptor(IConstants.IMG_ROW), null);

创建新行的方式是从调色板里拖动它到想要的位置。在拖动过程中,随着鼠标所在位置的变化,编辑器应该能显示一条直线,用来表示如果此时放开鼠标新行将插入的位置。由于这个工具代表的是一个单元格,所以缺省情况下GEF会显示一条与单元格长度相同的插入线,为了让用户感觉到是在插入行,我们必须改变插入线的宽度。具体的方法是在HeaderColumnPart的负责Layout的那个EditPolicy(继承FlowLayoutEditPolicy)中覆盖showLayoutTargetFeedback()方法,修改后的代码如下:

protected void showLayoutTargetFeedback(Request request) {
    super.showLayoutTargetFeedback(request);
    // Expand feedback line's width
    Diagram diagram = (Diagram) getHost().getParent().getModel();
    Column column = (Column) getHost().getModel();
    Point p2 = getLineFeedback().getPoints().getPoint(1);
    p2.x = p2.x + (diagram.getColumns().size() - 1) * (column.getWidth() + IConstants.COLUMN_SPACING);
    getLineFeedback().setPoint(p2, 1);
}

其中p2代表插入线中右边的那个点,我们将它的横坐标加上一个量即可增加这条线的长度,这个量和表格当前列的数目有关,和列间距也有关,计算的方法看上面的代码很清楚。这样修改后的效果如下图所示,拖动行到新的位置时也会使用同样的插入线。

图2 与表格同宽的插入线

选中整个行

缺省情况下,鼠标点击一个单元格会在这个单元格四周产生一个黑色的边框,用来表示被选中的状态。为了让用户能选中整个行,要修改HeaderCell上的EditPolicy。在前面一篇帖子里已经专门讲过,单元格作为列的子元素,要修改它的EditPolicy就要在ColumnPart的EditPolicy的createChildEditPolicy()方法里返回自定义的EditPolicy,这里我返回的是自己实现的DragRowEditPolicy,它继承自GEF内置的ResizableEditPolicy类,它将被HeaderColumnPart加到子元素HeaderCellPart的EditPolicy列表。现在就来修改DragRowEditPolicy以实现整个行的选中。

首先要说明,在GEF里一个图形被选中时出现的黑边和控制点称为Handle,其中黑边称为MoveHandle,用于移动图形;而那些控制点称为ResizeHandle,用于改变图形的尺寸。要改变黑边的尺寸(由单元格的宽度扩展为整个表格的宽度),我们得继承MoveHandle并覆盖它的getLocator()方法,下面的代码是我的实现:

public class RowMoveHandle extends MoveHandle {
    public RowMoveHandle(GraphicalEditPart owner, Locator loc) {
        super(owner, loc);
    }
    public RowMoveHandle(GraphicalEditPart owner) {
        super(owner);
    }
    //计算得到选中行所占的位置,传给MoveHandleLocator作为参考
    public Locator getLocator() {
        IFigure refFigure = new Figure();
        Rectangle rect=((HeaderCellPart) getOwner()).getRowBound();
        translateToAbsolute(rect);
        refFigure.setBounds(rect);
        return new MoveHandleLocator(refFigure);
    }
}

在getLocator()方法里,我们调用了HeaderCellPart的getRowBound()方法用于得到选中行的位置和尺寸,这个方法的代码如下(放在HeaderCellPart里是因为在Handle里通过getOwner()可以很容易得到EditPart对象),行尺寸的计算方法与前面插入线的情况类似:

public Rectangle getRowBound(){
    Rectangle rect = getFigure().getBounds().getCopy();
    Diagram diagram = (Diagram) getParent().getParent().getModel();
    Column column = (Column) getParent().getModel();
    rect.setSize(diagram.getColumns().size() * column.getWidth() + (diagram.getColumns().size() - 1) * IConstants.COLUMN_SPACING, rect.getSize().height);
    return rect;
}

有了这个RowMoveHandle,只要把它代替原来缺省的MoveHandle加到HeaderColumnCell上即可,具体的方法就是覆盖DragRowEditPolicy的createSelectionHandles()方法,ResizableEditPolicy对这个方法的缺省实现是加一个黑框和八个控制点,而我们要改成下面这样:

protected List createSelectionHandles() {
    List l = new ArrayList();
    //四周的黑色边框
    l.add(new RowMoveHandle((GraphicalEditPart) getHost()));
    //下方的控制点
    l.add(new RowResizeHandle((GraphicalEditPart) getHost(), PositionConstants.SOUTH));
    return l;
}

代码里用到的RowResizeHandle类是控制点的自定义实现,在下面很快会讲到。现在,用户可以看到整个行被选中的效果了。

图3 选中整个行

改变行的高度

改变行高度比较自然的方式是让用户选中行后自由拖动下面的边。前面说过,GEF里的ResizeHandle具有调整图形尺寸的功能,美中不足的是ResizeHandle表现为黑色(或白色,非主选择时)的小方块,而我们希望它是一条线就好了,这样鼠标指针只要放在选中行的下边上就会变成改变尺寸的样子。这就需要我们实现刚才提到的RowResizeHandle类了,它是ResizeHandle的子类,代码如下:

public class RowResizeHandle extends ResizeHandle {
    public RowResizeHandle(GraphicalEditPart owner, int direction) {
        super(owner, direction);
        //改变控制点的尺寸,使之变成一条线
        setPreferredSize(new Dimension(((HeaderCellPart) owner).getRowBound().width, 2));
    }
    public RowResizeHandle(GraphicalEditPart owner, Locator loc, Cursor c) {
        super(owner, loc, c);
    }
    //缺省实现里控制点有描边,我们不需要,所以覆盖这个方法
    public void paintFigure(Graphics g) {
        Rectangle r = getBounds();
        g.setBackgroundColor(getFillColor());
        g.fillRectangle(r.x, r.y, r.width, r.height);
    }
    //与前面RowMoveHandle类似,但返回RelativeHandleLocator以使线显示在图形下方
    public Locator getLocator() {
        IFigure refFigure = new Figure();
        Rectangle rect=((HeaderCellPart) getOwner()).getRowBound();
        translateToAbsolute(rect);
        refFigure.setBounds(rect);
        return new RelativeHandleLocator(refFigure, PositionConstants.SOUTH);
    }
    //不论是否为主选择,都使用黑色填充
    protected Color getFillColor() {
        return ColorConstants.black;
    }
}

这样,我们就把控制点拉成了控制线,因为它的位置与选择框(RowMoveHandle)的一部分重合,所以在界面上感觉不到它的存在,但用户可以通过它控制行的高度,见下图。

图4 改变行高的提示

正确的回显图形

我们知道,在拖动图形和改变图形尺寸的时候,GEF会显示一个”影图”(Ghost Shape)作为回显,也就是显示图形的新位置和尺寸信息。因为操作行时目标对象实际是单元格,所以在缺省情况下回显也是单元格的样子(宽度与列宽相同)。为此,在DragRowEditPolicy里要覆盖getInitialFeedbackBounds()方法,这个方法返回的Rectangle决定了鼠标开始拖动时回显图形的初始状态,见以下代码:

protected Rectangle getInitialFeedbackBounds() {
    return ((HeaderCellPart) getHost()).getRowBound();
}

这时的回显见下图,在拖动行时也使用同样的回显。

图5 改变行高时的回显

经过上面的修改,对HeaderCell的操作在界面上已经完全表现为对表格行的操作了。这些操作的结果会转换为一些Command,包括CreateHeaderCellCommand(创建新行,你也可以命名为CreateRowCommand)、MoveHeaderCellCommand(移动行)、DeleteHeaderCellCommand(删除行)和ChangeHeaderCellHeightCommand(改变行高)等,在这些类里要对所有列执行同样的操作(例如改变HeaderCell的高度的同时改变同一行中其他单元格的高度),这样在界面上才能保持表格的外观,详细的代码没有必要贴在这里了。

P.S.曾经考虑过另一种实现表格的方法,就是模型里只有Table和Cell两种对象,然后自己写一个TableLayout负责单元格的布局。同样是因为修改的工作量相对比较大而没有采用,因为那样的话行和列都要使用自定义方式处理,而这篇贴子介绍的方法只关心行的处理就可以了。当然,这里说的也不是什么标准实现,不过效果还是不错的,而且确实可以实现,如果你有类似的需求可以作为参考。

 

管理Oracle数据库要注意的一些问题

以下针对Oracle9i数据库:

  1. Commit操作不强制将database buffer内容写到文件;Commit操作后,server process在提示用户“操作已完成”之后才释放相关资源的锁;
  2. 创建数据库时,数据文件和日志文件必须用size指定大小,或用reuse指定到某个已有文件,否则命令会失败;
  3. 若丢失了所有control file的副本,可以通过重建control file恢复数据库;
  4. 在创建unique或primary key约束时,Oracle自动创建索引(名称同约束名),删除这个索引前必须先删除对应约束;
  5. Partitioned table可以被多个进程同时查询或操作;
  6. 当前的log sequence number被存放在control file和每个data file的头部(由CKPT进程写入),log group里的每个member具有同样的log sequence number;
  7. 通过DBA_OBJECTS表可以找到哪些对象存在错误,例如视图所依赖的表已被删除,这个视图的status会被标为invalide;
  8. Read-Only的表空间里的对象可以被Drop,因为该操作只影响dictionary;
  9. 当使用external验证方式时,不能指定password expire;
  10. DBA是role,而不是privilege(SYSDBA和SYSOPER是privilege);
  11. 使用truncate table命令后,并非所有extents都被释放,table将保留个数为minextents的extents;
  12. SMON后台进程负责数据库的recovery,以及合并碎片;
  13. 查询USER_XXX和dictionary表不需要具有select any table权限;
  14. 对于标志为unused的列,可以在同一张表中创建与它同名的列;
  15. Undo段在刚创建时是offline状态的;
  16. 用户自己唯一可以使用alter user命令修改的属性是identified by;
  17. 要修改tablespace的数据文件为自动扩展,应该使用alter database而不是alter tablespace命令;
  18. 创建用户和创建表的动作不记录在alertSID.log文件里;
  19. 没有”Create Index”权限,因为”Create Table”包含了它,Alter和Drop也一样;
  20. 具有”Create Any XXX”权限的用户在其他用户下创建的对象,其所有者是那个用户;
  21. Unlimited tablespace系统权限,只能直接授给用户,而不能授给角色;
  22. Externally管理的角色不能设置为default role;
  23. 没有”Truncate Table”权限,用户拥有”Drop Table”权限即可执行Truncate操作;
  24. Create SPFILE From PFILE命令可以反过来用,即Create PFILE From SPFILE,若不指定PFILE/SPFILE的名称则使用缺省名称;
  25. TableSpace的Storage选项里的Initial和Next值应为Minimum Extent值的整数倍,否则创建语句会失败;
  26. LogSwitch事件会记录在alert_log文件里;
  27. Oracle缺省使用AL16UTF16作为National Character Set,Database Character Set用于SQL和PL/SQL代码,National Character Set用于NChar、NVarchar2和NClob字段;Database Character Set不能使用固定长度多字节类型字符集;
  28. 对于Rollback Segment: minextents至少为2(推荐20),pctincrease永远为零,可以是public或private但一旦确定就不能更改,optimal参数至少为该segment的initial size,initial和next最好相等已保证每个extent具有相同的大小,maxextents最好不要设置为unlimited;刚创建时的roolback segment是offline状态的,必须手工设置为online才可用;drop前必须先设置为offline;
  29. 对于Temporary Tablespace和Temporary Segment: UNIFORM SIZE值最好是SORT_AREA_SIZE的整数倍;Tempfiles不能改名,不能只读,不会进行recovery处理,不能用alter database命令创建,总是nologging模式;
  30. 字典区管理的表空间可以指定自定义的storage选项;本地区管理的表空间的storage选项不可更改,可以指定为自动段空间管理;
  31. 待续。