mouseshuai的专栏

    周所周知，grant是给别的用户赋权限。他不只能够给表，视图赋权限，而且对存储过程，方法，以及包都可以，具体语法参考如下：     1.grant给表赋权限：     grant  select/update on  table to user；     grant  权限 on 表  to 用户。     2.grant 给存储过程赋权限：    

<br />环境：oracle11g<br /> <br /> <br />问题描述：在数据库中执行查看表空间利用率语句如下：<br /> <br />       select d.tp_name 表空间名,e.contents 类型,e.status 状态, e.extent_management 区管理,<br /><br />       b.bytes 大小m,  b.bytes-d.bytes 已使用m,(b.bytes-d.bytes)*100/b.bytes 占用率<br /><br /> 

数据库环境：oracle 9i主机：AIX 5.3现象：连接数据库超级慢，用topas查看主机的资源占用情况，一切正常。从数据库本机连接自己，只要是通过listener监听，就会连接很慢。如果用oracle用户，用sqlplus ’/as sysdba‘的方式去连接，则一切正常。于是发现是数据库listener的问题。于是去查看listener的日志，发现listener的日志在5个月以前就已经满了，导致listener进程不正常。解决办法：将listener日志清空，重新启动监听程序，一切恢复正常。

今天执行一条语句： INSERT INTO a@ora156  SELECT seq_sysalert_id.NEXTVAL,         15098727782 AS MSISDN,         0 AS MSTYPE,         sfafs AS MSMESSAGE,         0 AS MSFLAG    FROM DUAL 抛出错误码为O

  在pl/sql中，查询出n列数据，其中有中文，这时我想把里面的数据粘贴出来，但是粘贴出来以后，都是乱码。   解决办法：将输入法改为任意一种中文输入法，然后在拷贝出来，就没有问题了。

问题描述：用c++代码调用sqlldr入库大数据量的数据文件，有个字段是298的文本，数据库中的对应字段是varchar2（330），足够长了吧。然后入库，发现有好多长字段没有入库成功，而看sqlldr的执行日志发现是该字段过长，没有入库成功。是不是自己的数据库字段长度写错了？回去检查一把！发现并没有错误啊。原因：在google上查询一把，发现sqlldr有个字符串的默认长度设置是255，

背景：由于数据量巨大，共划分了20个表空间，其中做大的2t。现2t的表空间已经接近85%，必须进行清理，而用OEM等工具，直接跑不出结果。 转换思路：因为一个表空间上有n个user的表或者索引，可以各个击破，用每个用户登录，查看该用户在某个表空间上的信息。 用到的sql： select segment_name,sum(bytes)/1024/1024 FROM user_

在数据库中，有两个用户usera，userb，如果在b中有个存储过程，需要用a的用户去调用，（比如b是权限很高的用户，而a只是普通用户，为了屏蔽给a最小的权限只能如此）。于是，我就用grant execute on 存储过程名 to usera。这样，在a的用户下面就能看到存储过程了，但是我执行以后，还是报ora-1031，说是没有权限，经过于高手交流，说是需要将存储过程之中涉及的表的查询权限赋值

在oracle9i中建立一个dblink指向一个oracle11g的数据库，用户名、密码配置完毕以后测试，抛出这样的错误码： ORA-01017: invalid username/password; logon denied ORA-02063: preceding line from  然后不知所措，到网上一搜，找到一段英文解释，如下：CauseThe following

<br />今天晚上加班，有个存储过程，里面已经有4个dblink了，但是由于业务需要，还需要再加几个，在加到第五个的时候，系统忽然抛出一个错误：ora-02020 too many database links in use。咨询oracle工程师，得出的结论是在oracle的系统参数中，OPEN_LINKS和open_links_per_instanse两个参数设置问题，系统默认为4，并没有对这个参数修改。<br /> <br />操作：<br /> <br />1）用sys登录，<br /> <br