最近在Linux下开发,由于长期使用Visual Studio 2010,对代码提示功能情有独钟,现在在Linux下,使用Eclipse做开发,当然免不了怀念Visual Studio强悍的代码提示,于是在网上搜索了一些文章,整理出关于Eclipse代码提示功能设置的方法。

 

Java:

增强Eclipse 的代码提示功能,具体怎么样来配置?下面开始说步骤:
1. 打开Eclipse,然后“window”→“Preferences”
2. 选择“java”,展开,“Editor”,选择“Content Assist”。
3. 选择“Content Assist”,然后看到右边,右边的“Auto-Activation”下面的“Auto Activation triggers for java”这个选项。其实就是指触发代码提示的就是“.”这个符号。
4. “Auto Activation triggers for java”这个选项,在“.”后加abc字母,方便后面的查找修改。然后“apply”,点击“OK”。
5. 然后,“File”→“Export”,在弹出的窗口中选择“Perferences”,点击“下一步”。
6. 选择导出文件路径,本人导出到桌面,输入“test”作为文件名,点击“保存”。
7. 在桌面找到刚在保存的文件“test.epf”,右键选择“用记事本打开”。
8. 可以看到很多配置Eclipse的信息
9. 按“ctrl + F”快捷键,输入“.abc”,点击“查找下一个”。
10. 查找到“.abc”的配置信息如下:
11. 把“.abc”改成“.abcdefghijklmnopqrstuvwxyz(,”,保存,关闭“test.epf”。
12. 回到Eclipse界面,“File”→“Import”,在弹出的窗口中选择“Perferences”,点击“下一步”,选择刚在已经修改的“test.epf”文件,点击“打开”,点击“Finish”。该步骤和上面的导出步骤类似。
13. 最后当然是进行代码测试了。随便新建一个工程,新建一个类。在代码输入switch,foreach等进行 测试。你立即会发现,果然出了提示,而且无论是敲哪个字母都会有很多相关的提示了,很流畅,很方便。
 
C/C++:
 
打开终端:输入:$ gcc- v
得到类似的:gcc 版本 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
很容易就看到你当前使用的版本了。
启动Eclipse.进入:Windows-->Preferences-->C/C++找到Environment。增加两个变量:
CPLUS_INCLUDE_PATH: /usr/include/c++/4.1.3(我的gcc版本) 
C_INCLUDE_PATH: /usr/include
 
C/C++的代码提示只在.和->下触发,虽然没有Java下这么强大,不过也够了。因为这里是代码提示最容易发挥威力的地方。
 
补充:Ctrl+Space也能触发代码提示,而且功能更强,几乎总能给出符合需求的提示,不过我不知道如何才能让Eclipse在更多情况下自动触发提示,如果能做到,Eclipse就和Vistual Studio一样强了。
 
本文参考:
http://developer.51cto.com/art/200907/136242.htm
http://blog.chinaunix.net/u/21684/showart_462486.html

Oracle笔记—警示线

2010年9月11日 23:40

一些系统级的Warning警示线和Critical警示线谁大谁小没有严格规定。而像表空间这样的Warning警示线必须严格小于Critical警示线。其实我觉得严格小于是对的,不作规定反倒是很奇怪的。

Oracle笔记—Large Pool的作用

2010年9月11日 23:29

下面对象使用Large Pool:

MTS

—在SGA的Large Pool中分配UGA,语句的并行查询。

—允许进程间消息缓冲区的分配,用来协调并行查询服务器,备份。

—用于RMAN磁盘I/O缓存。

Oracle笔记—PL/SQL关键字问题

2010年9月11日 23:22

大概最容易用到的是SUM吧,Oracle内置函数名字,也是非常常用的变量名字,所以要注意,不要触及关键字。

Oracle笔记—Trace与Track

2010年9月11日 23:16

Oracle既有一个Track文件,也有一个Trace文件,Track和Trace解释很相近,以至于我长期搞不清楚他们的关系。

 

跟踪文件(trace file)能提供调试信息,服务器遇到问题时,它会生成一个包含大量诊断信息的跟踪文件。如果开发人员设置了sql_trace=true,服务器就会生成一个包含性能相关信息的跟踪文件。我们之所以可以使用这些跟踪文件,是因为oracle是一个允许充分测量的软件。编写数据库内核的程序员在内核中放入了调试代码,而且调试代码相当多,这些调试代码是被程序员有意留在内核中的。

 

修改跟踪文件(change tracking file)是一个可选的文件,这是oracle 10g企业版中新增的,这个文件惟一的目的是跟踪自上一个增量备份以来哪些块已经修改。采用这种方式,恢复管理器(recovery manager,rman)工具就能只备份确实有变化的数据库块,而不必读取整个数据库。
在oracle 10G之前的版本,要完成增量备份,必须读取整个数据库文件,查找自上一次增量备份以来修改的块,如果有一个1T的数据库,只增加了500M的新数据,增量备份就必须读取1T的数据,在其中找出要备份的500M新信息,尽管增量备份存储的数据确实少得多,但它还是要读取整个数据库。
在10G企业版中,oracle运行时,如果块被修改,oracle可能会维护一个文件,告诉RMAN哪些块已经修改。创建这个修改跟踪文件的过程相当简单,只需要通过ALTER DATABASE命令就可以完成:

Oracle笔记—CORE_DUMP_DEST

2010年9月11日 23:07

如果出现严重的oracle内部错误,或是oracle support要求你生成一个跟踪文件来得到额外的调试信息,CORE_DUMP_DEST参数则定义了此时这个“内核”文件应该放在哪里。

Oracle笔记—关于ASM_POWER_LIMIT

2010年9月11日 06:54

一直以为ASM_POWER_LIMIT是越小速度越快,但其实是越大速度越快拉。。

 

ASM_POWER_LIMIT specifies the maximum power on an Automatic Storage Management instance for disk rebalancing. The higher the limit, the faster rebalancing will complete. Lower values will take longer, but consume fewer processing and I/O resources.
 
If the POWER clause of a rebalance operation is not specified, then the default power will be the value of ASM_POWER_LIMIT.
 
引用自:http://united-states.frommeyer.nl/documentation/oracle/database/10.1/server.101/b10755/initparams012.htm

在10g中创建字典管理表空间都会出现这样一个错误:Failed to commit: ORA-12913: Cannot create dictionary managed tablespace

查询Oracle官方文档:

 

ORA-12913: Cannot create dictionary managed tablespace

Cause: Attemp to create dictionary managed tablespace in database which has system tablespace as locally managed

Action: Create a locally managed tablespace.

 

这是因为:

 

在Oracle920中,默认系统表空间是local管理,因此不能在数据库中建立数据字典管理的表空间。


如果想要建立数据字典管理的表空间,必须在建立数据库时,将系统表空间改为数据字典管理才可以。

 

一个是环境变量,一个是数据库参数。
 
nls_lang是在客户端设置设置客户端字符集,也就是在环境变量(Linux:~/.bash_profile)中。
 
nls_language在服务端设置,SERVER端的lang,属于parameter,可以由alter system set nls_language='...' scope=spfile 来修改。
 
nls_characterset也是设置服务器的字符集。

Oracle笔记

2010年9月10日 06:11

“如果使用专用服务器连接,会在USER_DUMP_DEST参数指定的目录中生成跟踪文件。如果使用共享服务器连接,则在BACKGROUND_DUMP_DEST参数指定的目录中生成跟踪文件。”

网上来的,这句话似乎是有问题的,因为我的测试数据库自安装起就是用专用服务器连接,但是BACKGROUND_DUMP_DEST依旧有大量Trace文件。还是“bdump是有关后台进程的trace,udump是有关用户的”更正确些。