Ⅰ 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).降低查詢的運行時間。(推薦做法)。