二十:更改SGA的操作
alter system set xxx=xxx scope=spfile,只在spfile参数文件修改,要重启数据库修改才生效
alter system set xxx=xxx scope=both,既修改当前实例,又在spfile参数文件修改.
alter system set xxx=xxx scope=memory只修改当前实例,不在spfile参数文件做修改
另外,修改静态参数,scope只能是指定spfile,否则会报错,要重启才能生效.
如果不指定scope,默认是both.
有很多参数你想把它设置为0是不可能的！ large_pool_size 只要在几个条件下才能为0，例如：db_io_slave为0，还有不能是shared sever等等记不清了，看oracle文档吧
类似的还有java_pool_size，设成0，没戏！

第一你没有办法将它设置为0，
第二 java_pool_size太小，在进行建库的时候，建库程序本身就是一个java程序，需要一下java 池空间，太小就导致程序出错。 类似的情况，就是进行db升级，例如从9201到9206，在升级时，必须将java池设置为117M左右，然后才能保证成功（主要在最后运行编译pl/sql包的2步）。 我们可以在升级成功后，在把java池改下.
二一：可以创建150G的表空间吗？
SQL>create tablespace taipinglife datafile '/backup/oradata/ora10/taipinglife.dbf' size 150000M ;
create tablespace taipinglife datafile '/backup/oradata/ora10/taipinglife.dbf' size 150000M
ORA-01144: File size (19200000 blocks) exceeds maximum of 4194303 blocks
************************************************************
超过了每个数据文件允许的最大block数了。
建议分成10个15G的数据文件

对于Oracle9i Database Blocks
Maxnumber per datafiles Platform dependent(依赖于数据库平台) ; 典型的为2的22次方-1 blocks。

使用10G的Bigfile Tablespaces就可以用一个文件搞定
但还是建议象楼上说的，分多个文件吧，比如分成50个文件
这样操作就可以了：
create tablespace taipinglife datafile
'/backup/oradata/ora10/taipinglife_01.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_02.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_03.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_04.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_05.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_06.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_07.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_08.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_09.dbf' size 15000M ,
'/backup/oradata/ora10/taipinglife_10.dbf' size 15000M;

二二：导入150G的数据，给点建议谢谢 ！

机器的空间剩余情况，要导入150G的数据，各位高人给点建议，谢谢
[root@DB3 backup]# df -h
文件系统 容量 已用 可用 已用% 挂载点
/dev/cciss/c0d0p3 9.7G 8.1G 1.1G 89% /
/dev/cciss/c0d0p8 489G 126G 338G 28% /backup
/dev/cciss/c0d0p1 99M 15M 80M 16% /boot
/dev/cciss/c0d0p2 29G 18G 11G 63% /home
none 2.0G 0 2.0G 0% /dev/shm
/dev/cciss/c0d0p7 2.0G 33M 1.8G 2% /tmp
/dev/cciss/c0d0p6 2.0G 1.2G 713M 62% /var

利用管道吧，设置20个进程，每个进程buffer 4M, 100M的交换磁盘空间就搞定了
那150G的数据，不会是1个表吧？如果是一个表，那就1个进程也可以。根据机器和网络的情况，估计最慢1小时也搞的定。如果是分布在多个表的，就按表导。根据表的大小，平均分配到多个进程中。

下面以AIX操作系统为例，写个DEMO
mkfifo fifo_${v_tname}
exp ${v_fromuser}/${v_frompass}@${v_service_name} tables=${v_tname} grants=n file=fifo_${v_tname} triggers=n indexes=n buffer=4096000 &
imp ${v_touser}/${v_topass} fromuser=${v_fromuser} touser=${v_touser} file=fifo_${v_tname} ignore=y
rm fifo_${v_tname}
这样做，一个最大的好处，就是可以在有限的磁盘空间下，照样完成数据迁移，另一个好处就是效率了，不能等你EXP出来后再IMP。如果对时间和空间要求都比较紧张的话，这是一个不错的方法。意思是建个管道直接导入，而不用生成中间文件。查了一下，mkfifo在Linux下也是一样直接用那个DEMO脚本就OK。
二三：登陆SQLPLUS的时候报错如下信息
SQL> conn cws3/cws3
Error accessing PRODUCT_USER_PROFILE
Warning:  Product user profile information not loaded!
You may need to run PUPBLD.SQL as SYSTEM
Connected
的解决办法？
主题：使用product_user_profile来实现用户权限的设定
我们有时候在以普通用户登录SQL*Plus的时候，会碰到下面的错误提示：

Error accessing PRODUCT_USER_PROFILE
Warning: Product user profile information not loaded!
You may need to run PUPBLD.SQL as SYSTEM
其实在实际意义上这只是一个警告而已，并不是真正的错误，遇到这个提示，并不会影响我们正常使用SQL*Plus，也不会对数据库功能产生影响。
如果数据库是使用dbca创建的那么不用担心这个问题，通常是我们手动创建数据库的情况下，忘了执行一些脚本才导致出现这样的警告。PRODUCT_USER_PROFILE其实有很强大的功能，这是SYSTEM模式下的一个表，在此表中存在的数据可以让客户端程序登入的时候检查是否在命令的执行上有什么限制。基本上我们是以它来限制SQL*Plus这个客户端程序（目前好像也只有这个程序才会去自动检查这张表:D）
如果不想看到这个警告，作如下操作：
以SYSTEM用户登入SQL*Plus，然后执行PUPBLD.SQL，这个文件通常在$ORACLE_HOME/sqlplus/admin目录中。
SQL> @$ORACLE_HOME/sqlplus/admin/pupbld.sql
执行完毕以后，可以desc product_user_profile来验证一下改表已经创建，并且熟悉一下表的结构。
以上不是这篇小文章的重点，下面我们要利用这张表来限制SCOTT用户不能执行DROP命令，即使SCOTT用户拥有DROP TABLE的权限。
SQL> insert into product_user_profile (
  2  product, userid, attribute, char_value)
  3  values (
  4  'SQL*Plus','SCOT%','DROP','DISABLED');
1 row inserted
Executed in 0.01 seconds
SQL> commit;
Commit complete
Executed in 0 seconds
然后退出SYSTEM用户，用SCOTT用户登录，作个测试：
SQL> create table t_test_profile(
  2  id number);
Table created.
Elapsed: 00:00:00.10
SQL> drop table t_test_profle;
SP2-0544: invalid command: drop
这就是product_user_profile的作用，回顾一下：
1。如果我们把DROP改成CREATE或者UPDATE那么就对用户禁止了这些命令。
2。从上面的insert语句，我们可以看到对于用户的限制支持通配符，所有以SCOT开头的用户都不能执行指定的命令。
3。修改了product_user_profile内容，用户必须重新登录SQL*Plus，修改才会生效，也就是只有在登录的时候，SQL*Plus才会检查一遍product_user_profile表中的内容。