Ⅰ sql中删掉一张表的时候需要注意什么
1. 删除表的注意事项
在删除一个表中的全部数据时，须使用TRUNCATE TABLE 表名;因为用DROP TABLE，DELETE * FROM 表名时，TABLESPACE表空间该表的占用空间并未释放，反复几次DROP，DELETE操作后，该TABLESPACE上百兆的空间就被耗光了。
2.having 子句的用法
having 子句对 group by 子句所确定的行组进行控制,having 子句条件中只允许涉及常量,聚组函数或group by 子句中的列.
3.外部联接"+"的用法
外部联接"+"按其在"="的左边或右边分左联接和右联接.若不带"+"运算符的表中的一个行不直接匹配于带"+"预算符的表中的任何行,则前者的行与后者中的一个空行相匹配并被返回.若二者均不带’+’,则二者中无法匹配的均被返回.利用外部联接"+",可以替代效率十分低下的 not in 运算,大大提高运行速度.例如,下面这条命令执行起来很慢
用外联接提高表连接的查询速度
在作表连接(常用于视图)时，常使用以下方法来查询数据:
SELECT PAY_NO, PROJECT_NAME
FROM A
WHERE A.PAY_NO NOT IN (SELECT PAY_
NO FROM B WHERE VALUE >;=120000);
---- 但是若表A有10000条记录，表B有10000条记录，则要用掉30分钟才能查完，主要因为NOT IN要进行一条一条的比较，共需要10000*10000次比较后，才能得到结果。该用外联接后，可以缩短到1分左右的时间:
SELECT PAY_NO,PROJECT_NAME
FROM A,B
WHERE A.PAY_NO=B.PAY_NO(+)
AND B.PAY_NO IS NULL
AND B.VALUE >;=12000;
4.set transaction 命令的用法
在执行大事务时,有时oracle会报出如下的错误:
ORA-01555:snapshot too old (rollback segment too small)
这说明oracle给此事务随机分配的回滚段太小了,这时可以为它指定一个足够大的回滚段,以确保这个事务的成功执行.例如
set transaction use rollback segment roll_abc;
delete from table_name where ...
commit;
回滚段roll_abc被指定给这个delete事务,commit命令则在事务结束之后取消了回滚段的指定.
5.数据库重建应注意的问题
在利用import进行数据库重建过程中,有些视图可能会带来问题,因为结构输入的顺序可能造成视图的输入先于它低层次表的输入,这样建立视图就会失败.要解决这一问题,可采取分两步走的方法:首先输入结构,然后输入数据.命令举例如下 (uesrname:jfcl,password:hfjf,host stingra1,数据文件:expdata.dmp):
imp jfcl/hfjf@ora1 file=empdata.dmp rows=N
imp jfcl/hfjf@ora1 file=empdata.dmp full=Y buffer=64000
commit=Y ignore=Y
第一条命令输入所有数据库结构,但无记录.第二次输入结构和数据,64000字节提交一次.ignore=Y选项保证第二次输入既使对象存在的情况下也能成功.
select a.empno from emp a where a.empno not in
(select empno from emp1 where job=’SALE’);
倘若利用外部联接,改写命令如下:
select a.empno from emp a ,emp1 b
where a.empno=b.empno(+)
and b.empno is null
and b.job=’SALE’;
可以发现,运行速度明显提高.
6.从已知表新建另一个表：
CREATE TABLE b
AS SELECT * (可以是表a中的几列)
FROM a
WHERE a.column = ...;
7.查找、删除重复记录:
法一: 用Group by语句 此查找很快的
select count(num), max(name) from student --查找表中num列重复的，列出重复的记录数，并列出他的name属性
group by num
having count(num) >;1 --按num分组后找出表中num列重复，即出现次数大于一次
Ⅱ 用expdp导出报错求教ORA-39126，ORA-01555
你好。
这个是回滚段太小，
之后又大量事务重用回滚段，导致延迟块清除的数据被覆盖
短期解决：
alter system set "_offline_rollback_segments"='_SYSSMU8_1682283174$' scope=spfile;
alter system set "_corrupted_rollback_segments"='_SYSSMU8_1682283174$' scope=spfile;
长期解决
增加undo_tableapace的大小，
增加undo_retention的时间，
如果我的回答没能帮助您，请继续追问。
Ⅲ 数据恢复时，“ORA-01555快照过旧”
这个是由于你的数据库的这个表的对应undo已经覆盖，无法通过该方法恢复delete数据
如果数据重要，无法自行解决，可以联系我们，通过另外的方法恢复oracle 被delete数据
网页链接
Ⅳ 设置show parameter undo 需要重启数据库吗，最近跑一个存储过程，老出现ora-01555回滚段太旧错误，请教一
show parameter undo 只是个相当于select 的查询，当然不需要重启。
你可以考虑把 undo_retention设大 一点试试
比如
SQL> alter system set undo_retention=1800;
也不需要重启
Ⅳ 重装Oracle后,怎么才可以还原.ora 数据库文件
在重装oracle前，必须对数据进行备份，通常有两种方法：1.
冷备份
，将oracle下oradata文件下的内容全部拷贝下来，这也叫物理备份，这个文件夹一般比较大。
2.
逻辑备份
，在oracle下导出dmp
数据文件
，这个比较小，可安全性不高。
要还原重装以前的数据文件，象第一种情况，可直接把备份的oradata文件拿来覆盖刚装好的oradata文件就可以了。第二种dmp格式的比较麻烦，用plsql进入，在tool菜单下选imp导入数据。
Ⅵ 系统提示ora－01555，如何加大rollback segment
Oracle enforces statement-level read consistency. This ensures that the data returned by a single query is consistent with respect to the time when the query began. Therefore, a query never sees the data changes made by transactions that commit ring the course of execution of the query. Usually, a long running query has error ORA-1555 if the data accessed by the query is updated and committed by another user or session after the query has been started. The most common reasons for error ORA-1555 (snapshot too old) are: A long running query e to a poorly qualified data access A high processing time between fetches of the same query Incorrect rollback segment setup A long run query can cause some activities in the ABAP program loop to take too long, even if the SQL statement is correct. For example: SELECT ... Fetch (a long running activity) ENDSELECT Before you try to change the number or size of the rollback segments, check if the problem is caused by expensive queries, such as inefficient application design, wrong index design, or insufficient cost-based optimizer statistics. You can adjust the rollback segment setup by adding more rollback segments or making them larger. you can please have a look at SAP notes 60233 to increase rollback segment size/number. suggest: increase rollback segment number to 40 frist. if you still meet ORA-01555 increase the size.
Ⅶ oracle 的错误ORA-01555快照太旧是如何产生的，就是所什么情况下产生这个错误请指教。
有点复杂，简单的说是因为undo表空间中inactive状态的数据块被重复使用而导致数据库itl槽undo快地址被覆盖的问题，引起这个错误的主要原因可能是undo表空间太小或者sql的执行时间过长，如果想搞清楚到底为什么，建议看看undo的原理与作用方面的资料。
Ⅷ 关于SQL的约束。
如果是创建表的话：
create table Sobject
(SoNumber varchar2(10) check (SoNumber like 'S01%')
);
如果是修改已有的表
alter table Sobject modify(SoNumber varchar2(10) check (SoNumber like 'S01%'));
另外 因为类型是varchar2,所以执行insert的时候要加''，如：
insert into Sobject(SoNumber) values ('S01555');
以上都是针对oracle数据库
其他的数据库 数据类型自行修改。。。
Ⅸ 请教oracle一个查询的问题
show parameter undo_retention;
检查下回滚段的大小,把回滚段改大一点看看
Ⅹ Oracle数据库 ORA
发生ORA-01555有以下几种原因:
(1).查询SQL执行时间过长，回滚段太小。
(2).系统频繁进行DML操作，导致UNDO循环复写很快。
(3).块清除(8i以后很少发生)
下图模拟了(1),(2)情况ORA-01555发生的过程
0:00 查询开始
0:01 另一个会话UPDATE块1000000，回滚信息记录在回滚段上。
0:01 update会话commit。回滚段仍在那里，但是会被复写。
1:00 查询仍在进行 在块200000上
。。。。。期间进行了大量的DML操作，不断向undo中写入
4:00 查询仍在进行 在块600000上。
4:01 UNDO已满，开始覆盖，将0:01写入的回滚段覆盖。
4:30 查询到1000000时 发现查询开始已经被修改了，进入回滚段试图找到那个块的撤销信息，从而得到一致读。这时发现需要的信息已经不存在，ORA-01555出现，查询失败。
(3)发生的情况是:下一个session在块修改后第一次访问它时，需要检查最后修改块的事务是否仍被激活，一旦确定没有激活就执行清除块操作。为了清除块，ORACLE需要访问前一事务的回滚段，但是发现该回滚段已经被复写，这时也会发生ORA-01555.
解决和预防的方法有:
(1).使用合适大小的事务，没有提交太频繁。
(2).增加更多的回滚段，延长undo区被复写的时间。
(3).降低查询的运行时间。(推荐做法)。