sql遞歸演算法

1. 菜鳥 Sql語句求解 最好把每一句都解釋 一下 不勝感激、、

指定資料庫
USE [Student]
GO
以下為系統自動生成的，一般沒什麼用，除非你改變了系統的環境
/****** Object: Table [dbo].[C] Script Date: 04/19/2011 21:25:17 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

建立數據表
CREATE TABLE [dbo].[C](
指定欄位名稱，類型，長度，是否允許為空
[Cno] [nchar](10) NOT NULL,
[Cname] [nchar](20) NULL,
[Credit] [float] NULL,
[Property] [nchar](14) NULL,
設置主鍵
CONSTRAINT [PK_C] PRIMARY KEY CLUSTERED
(
[Cno] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
/****** Object: Check [CK_C] Script Date: 04/19/2011 21:25:17 ******/
增加檢查CK_C，並且作用於剛才新建的表
ALTER TABLE [dbo].[C] WITH CHECK ADD CONSTRAINT [CK_C] CHECK (([Credit]>(0)))
GO
ALTER TABLE [dbo].[C] CHECK CONSTRAINT [CK_C]
GO

靠記憶寫的，你對應查一下幫助就明白了

2. sql 怎麼遞歸查詢的方法：

1．創建測試表，createtabletest＿connect（idnumber，p＿idnumber）；

3. 急需SQL server 2005的介紹

前言

SQL Server 2000從上市到現在已經整整五個年頭。現在望眼欲穿的SQL Server 2005 終於發布了。五年磨一劍，SQLServer 2005 將是微軟具有里程碑性質的企業級資料庫產品。本文從用戶關心的技術要點出發比較和討論SQL Server 2005 相對它的前版本SQL Server 2000所做的重大改進或新增功能，介紹了SQL Server 2005 中最值得你為之升級的10 個理由。無論你是想了解或學習SQL Server 2005，還是正在評估或考慮升級到SQL Server 2005，本文都將對您有很好的參考作用。

升級理由一：數據分區
只有到了2005 版本SQL Server才擁有了真正的表和索引數據分區技術。這個技術一下子使SQL Server資料庫從「青壯年」成長為成熟的企業級資料庫產品，是一個里程碑性質的標志。數據分區技術極大加強了表的可伸縮性和可管理性，使得 SQLServer 處理海量數據的能力有了質的飛躍，是我認為最值得升級的一個理由。

資料庫隨著硬體和業務的發展變得越來越大。五年前大多數資料庫還不過是十幾個GB大小，很少超過TB級別的。現在幾百個GB大小的資料庫系統隨處可見。如果沒有數據分區技術而想對大資料庫進行高效管理是很困難的。SQL Server 2005以前版本的一個問題是隨著時間的推移資料庫越來越大，備份需要的空間越來越多，如何處理資料庫中的歷史數據是很棘手的事情。有些客戶可能會使用 DELETE語句定期定量刪除大表中的歷史記錄，如在每個周末備份資料庫後刪除一個星期以前的所有數據。但是如果表有上千萬行十幾個GB 大小，那麼使用DELETE語句刪除資料庫中上萬行或高達20%數據的話，其性能很差。如果是在7 × 24小時運行的聯機系統做這樣的數據維護操作那麼還會引起比較嚴重的阻塞問題。另外有些客戶針對這個問題直接在方案設計上下功夫，比如按照年份月份星期設計表，然後定期把一些過時的歷史數據表（注意是「表」）備份並DROP掉，使得資料庫大小以及系統性能都能保持相對穩定。但是這種方法有一個弊端，即應用程序必須做相應的配合根據不同的時間訪問對應的表，增加了資料庫管理以及資料庫訪問邏輯的復雜性。

大表還容易帶來性能問題。你也許會想到SQL Server 2000中的本地分區視圖或分布式分區視圖技術。是的，SQL Server2000 中的確已經有分區視圖的概念，從SQL Server 7.0開始就有了。可惜分區視圖的一個令人討厭的地方是其管理、設計和開發比較困難，特別是分布式分區視圖。如如何更新分布式視圖就是個難題。所以盡管一個設計良好的分區視圖系統會有很不錯的性能改善，卻因為繁瑣的配置，管理和開發使得其沒有在實際中得到充分應用。

現在，SQL Server 2005 引入了真正的數據水平分區技術，上面討論的資料庫增長問題和性能問題就迎刃而解。這個進步絕對不是一小步。資料庫的大小不再是個問題。你可以根據欄位值的范圍將表和索引劃分為多個分區從而可以輕松管理一個幾個TB大小的資料庫系統。無論數據如何增長，你都可以使用分區技術使得資料庫大小保持相對穩定。其中特別值得稱贊的地方是SQL Server 2005 中分區的管理和使用非常簡單。分區的刪除，添加，拆分、合並和移動，以及分區的數據裝載等管理都非常容易。你可以對單獨的分區進行維護而不是整個表。如果你需要大量裝載數據，那麼你可以先把數據並行的裝入到一個新分區當中，建立索引，然後把該分區合並到當前分區中來。這個動作需要的時間極短。如果你需要刪除歷史數據，假設你已經設計好了歷史數據分區，那麼你僅僅需要把該分區移除即可，幾乎可以一瞬間完成。分區也使得大型表的並發訪問性能得到改善，特別是有多個CPU的資料庫系統。那些需要交叉訪問大量數據的查詢將從分區技術中獲益不少。

升級理由二：可編程性
CLR 集成

SQL Server 2005的可編程性是值得升級的第二個重要理由。從來沒有哪一個版本能像SQL Server 2005 這樣帶來這么多編程方面的變革。說老實話，在我知道的瞬間我是驚呆了。有些變化是革命性的。如CLR（Common Language Runtime,公共語言運行時）集成。就先說說CLR集成。CLR集成是指你可以使用任何一種.NET 語言編寫SQL Server 2005 的存儲過程，觸發器，函數，自定義類型，甚至是自定義的聚合函數。估計不少資料庫軟體開發商會為這個功能歡呼雀躍。想想以前的擴展存儲過程，編程非常不容易。代碼中一不小心就會引起內存泄漏。而且由於擴展存儲過程運行在SQL Server 的進程空間中，不好的代碼容易引起訪問違規（Access Violation）導致SQLServer 異常。

現在有了CLR 集成，你可以輕松利用.NET語言的優勢如其面向對象的封裝、繼承和多態特性，編寫出那些需要對數據進行復雜數值計算或邏輯的代碼，如字元串處理，數據加密演算法，XML數據操作等等。由於CLR代碼宿於SQL Server進程，你可以非常容易訪問資料庫中的數據。有了CLR，你不再局限於T-SQL，你現在立即擁有了.NET 框架類庫提供的各種各樣的類和常式，以及.NET語言提供的一致的編程模型，如錯誤處理。展現在你面前的是一個可以無限擴展的編程空間。你現在需要的僅僅是考慮什麼時候使用T-SQL 語言，什麼時候使用CLR。我猜測那些SQL Server軟體開發商幾乎會立即升級到SQLServer 2005 享受資料庫編程的便捷。

T-SQL 語言增強
SQL Server 2005 中的T-SQL語言有了非常大的改進。其中筆者最為稱道的是現在可以使用和C++或C#類似的TRYCATCH結構對T-SQL 進行錯誤處理了，大大簡化了T-SQL錯誤處理編程。SQL Server 2005以前的版本通過設置@@error變數表示最後的T-SQL 語句執行成功與否。為避免@@error變數被新執行的語句重置，你必須為每一條可能出錯的TSQL語句後面立即檢查或保存@@error變數的值，並使用相應的G O T O 語句進行跳轉，使得代碼變得復雜難讀。現在SQLServer 2005 有了TRY-CATCH結構你只需要把相關的一組語句放在TRY塊裡面即可。如果TRY塊裡面任何語句發生錯誤，就會執行相應的CATCH 塊。你甚至可以使用嵌套的TRYCATCH來實現復雜錯誤處理流程。估計很多T-SQL語言使用者可能就為了這個TRY-CATCH 結構而迫不及待地升級到SQL Server 2005。

除了傳統的DML（INSERT/UPDATE/DELETE）觸發器，SQL Server 2005 現在也可以對DDL 語言（CREATE、ALTER或DROP 開頭的語句）創建觸發器了。這對於那些需要對DDL語言執行管理任務如審核以及規范資料庫操作的用戶特別有用。以前很多客戶問我如何跟蹤或避免表的刪除操作，現在終於有了答案。你可以簡單建立一個針對DROP 語句的觸發器然後在觸發器裡面ROLLBACK 事務就可以回滾DROP 動作了。

SQL Server 2005 T-SQL 中還有一個很酷的OUTPUT 子句。現在你不費吹灰之力就可以獲得INSERT 、UPDATE 或DELETE語句所影響的每行的信息。對於在INSERT或UPDATE操作之後需要檢索標識列或計算列的值的場合OUTPUT子句非常有用。如獲得數據INSERT 後該行的Identity的值，產生一些唯一流水號，驗證剛剛插入的數據等等。一個有趣的例子是Identity值的取得。在SQL Server 2000 中你可以在INSERT 語句後立即調用IDENT_CURRENT()或SCOPE_IDENTITY()函數來得到INSERT 語句的Identity。現在你僅僅需要在INSERT 語句中指定output子句就直接得到剛剛插入的Identity值，實在太簡單了，不是嗎？

SQL Server 2005 中T-SQL 語言新增或加強的功能還有很多。如SQL Server 2005 新增加了一類排名函數RANK/DENSE_RANK/NTILE/ROW_NUMBER，輕松解決了開發者要求返回數據行中提供行號等排序功能。新增的 P I V O T 和UNPIVOT運算符使得對結果集進行行和列的旋轉變換十分簡單。公用表表達式(CTE)解決了T-SQL語言的遞歸查詢問題，而使用 OPENROWSET 語句現在可以直接從文件裡面執行大容量操作了。我覺得每一個改進都是那麼有針對性，以至於使我相信這些T-SQL增強必定是SQL Server開發小組真正聆聽資料庫開發者心聲的結果。

升級理由三：安全
SQL Server 2005 的安全功能是我認為值得升級的第三個理由。SQL Server 2005 的安全達到了前所未有的強大水平，有著比以前版本更清晰的安全模型即主體，安全對象和許可權。在SQLServer 2000 中是用伺服器級許可權、資料庫角色和數據用戶許可權的混合方式管理許可權。而SQL Server 2005 統一使用GRANT語句管理主體對安全對象的許可權，簡化了安全管理。其中我認為最大的改進是用戶和架構（schema）分離。在SQL Server 2000中如果用戶不是DBO 且擁有對象，那麼移除該用戶將是很麻煩的事情。你需要首先使用sp_changeobjectowner改變該用戶擁有的對象所有權，然後把所有引用該對象的代碼做相應的修改。而在SQL Server 2005 中就不需要這樣麻煩了，因為現在用戶不再擁有對象。擁有對象的是schema 而不是用戶。資料庫中的所有對象都屬於某個schema。對象的完整名字是server.database.schema.object，符合SQL- 99 標准，而不是以前的server.database.user.object 方式。刪除用戶僅需要改變schema的owner就可以了。不需要修改任何已存在的資料庫訪問代碼，真的很方便。用戶和架構分離還有一個好處就是對象的許可權管理變得簡單。你可以把某些對象集中於某個架構裡面，然後對該架構設置許可權，那麼架構裡面的所有對象就自動繼承了同樣的許可權。

如果你需要保護資料庫中的敏感數據，那麼SQL Server2005 中的數據加密功能絕對值得考慮。以前不止一次有客戶問我如何加密資料庫中的某些數據，是否可以使用一些內部不公開的函數如PWDENCRYPT加密數據。我的回答是使用Windows的EFS（加密文件系統）功能加密資料庫文件或在應用程序層對數據加密後再存儲。現在用戶期盼已久的數據加密功能終於在 SQL Server 2005 中得到實現，那些有機密數據需要保護的用戶值得高興了。SQL Server 2005不是簡單的提供一些加密函數，而是把市場上已經成熟的數據安全技術引進到資料庫中，有一個清晰的加密層次結構。SQL Server 2005 支持證書（certificate），非對稱密鑰和對稱密鑰演算法，一是防止敏感數據被泄漏，二是防止數據被篡改。對稱密鑰支持RC4，RC2， TripleDES 和AES演算法，而非對稱密鑰使用RSA 演算法。證書其實就是非對稱密鑰中公鑰的容器。密鑰管理是安全中比較弱的部分。SQL Server 2005 每一層都使用證書、非對稱密鑰和對稱密鑰的組合對它下面的一層進行加密，提高了密鑰安全性。出於性能考慮，一般不用加密強度大的非對稱密鑰或證書直接加密數據，而是使用對稱密鑰加密數據獲得較快的性能，然後使用證書或非對稱密鑰加密對稱密鑰。

升級理由四：快照隔離
你還在為系統出現的阻塞（blocking）或死鎖（deadlock）現象苦惱嗎？快試試SQL Server 2005 中的快照隔離吧。通過行版本（row versioning）控制技術，SQL Server 2005 除了原來支持的四種事務隔離級別（臟讀、提交讀、可重復讀、可串列讀）外新增了一個快照（SNAPSHOT）隔離級別，有可能使阻塞或死鎖成為歷史。 SQL Server在TEMPDB中存放不同版本的數據行，select 語句讀取這些不同版本的行，讀操作不阻塞寫數據，寫操作也不阻塞讀操作，這樣那些由於讀/ 寫爭用導致的大量死鎖的系統將從中獲得無窮益處。如果你的系統復雜難優化，那麼升級到SQL Server 2005 試試快照隔離級別，也許會有意想不到的效果。

SQL Server 2005中的快照隔離可細分為兩種即READ_COMMITTED_SNAPSHOT和ALLOW_SNAPSHOT_ISOLATION。建議大家多使用前者，因為已提交讀隔離可用於大多數現有應用程序，而不需要進行任何更改，其佔用的TEMPDB空間也少。可以預見如果使用快照隔離級別，那麼需要特別關注TEMPDB的大小和性能。你也許需要把TEMPDB放在有足夠空間的單獨磁碟上以提高性能。

考慮到快照隔離在避免阻塞和死鎖方面的作用，我把它作為升級的第四個理由。

升級理由五：資料庫鏡像
對於那些要求高可用性的用戶來說，資料庫鏡像也許是考慮升級的唯一理由。SQL Server 2005的前版本在高可用性方面提供了故障轉移群集（Failover Cluster）和Log shipping方案。群集方案的一個好處是在一台機器發生問題時它可以提供極快的故障轉移能力，在備份伺服器上聯機資料庫，應用程序只需重新連接即可。群集方案的一個缺點是資料庫放在共享盤上，有單點失效這個缺點，一旦共享盤失敗將導致整個系統崩潰。所以群集方案一般都要結合嚴緊的備份方案一起使用。而 logshipping系統有一個時間上的延遲，且如果日誌備份很大，傳送速度也是個問題。SQL Server 2005引入的資料庫鏡像可作為故障轉移群集或Log shipping 的替代或補充方案來提高資料庫的高可用性。鏡像的主要優點是它比前兩者更容易管理，沒有群集的單點失效缺點,也沒有log shipping 的時間延遲。鏡像伺服器可以放在很遠的地方，提高了作為備份伺服器的高可用性。

資料庫鏡像需要兩台或三台伺服器。主伺服器通過傳送事務日誌中的每個事務到鏡像伺服器來進行數據同步。每當資料庫commit一個事務，該事務就會被同步到鏡像伺服器。如果事務安全設置為FULL，傳送操作將為同步操作。同步操作可以確保將提交的事務提交給兩個伺服器，但可能會增加事務提交的時間。如果事務安全設置為OFF，操作將為非同步操作。事務會在不等待鏡像伺服器的情況下提交，這將不影響主伺服器事務的提交時間，但不能確保鏡像也提交了該事務，所以在出現故障那一刻有可能有部分日誌丟失。對於需要嚴格同步數據的鏡像系統可以採取同步模式。而僅僅希望有個備份伺服器又不影響性能的情況下可以使用非同步模式（高性能模式）。無論那種模式，一旦主伺服器出現問題，你可以手動實現故障轉移或配置系統實現自動故障轉移。

升級理由六：商務智能BI 增強
SQL Server 2005 對已經有或打算開發基於SQL Server 的商務智能方案的用戶吸引力極大。SQL Server 2005中有關商務智能方面的增強很多，是升級的很好理由。首先是傳統的DTS（Data Transformation Services）被新的IS（Integration Services）代替。SQL Server 2000 中的DTS用來在不同伺服器之間轉移數據，但對於復雜重復的工作流DTS倍感吃力。IS重新改寫了DTS的數據流引擎，引入提取、轉換和載入（ETL）數據的新編程體系，將數據流與控制流分開，開發能力大大加強，包部署、管理和性能方面也比DTS上了一個數量級。筆者看來，DTS終於從原來的小打小鬧成長為成熟的IS 數據集成服務體系。

分析服務（Analysis Services）在SQL Server 2005 中也有很多改進。原來沒有profiler想跟蹤分析服務裡面的語句非常痛苦。現在2005 終於支持profiler了。Profiler對性能調優和排查錯誤將非常有用。分析服務2005 真正具備了實時分析能力，新增加了四種數據挖掘演算法，也支持.NET語言進行開發（如存儲過程等）。至於報表服務，2005 版本中添加了報表生成器和模型設計器這兩個新工具，支持報表拖拉設計。2005 的報表改進如新的列印功能、多值參數等。設計過報表的人員會深深知道多值參數的妙處。
另外，無論是IS、報表服務等都可以在類似Visual Studio的環境中開發，任務完成不過滑鼠拖拉之間，非常容易上手。

升級理由七：全文搜索增強
相對前版本SQL Server 2005中性能提升最多的部分當數全文檢索。SQL Server 2000 中的全文本檢索和SQL Server 7.0中的差別不大，處於能用的水平。在SQL Server 2000中使用全文檢索一個最大的痛苦是建立全文索引的性能不好，需要的時間太長，特別是在表很大的情況下。一個幾千萬行數據的表也許需要數個小時到數天時間才能完成全文索引的建立。SQL Server 2005全文檢索在開發的時候就集中於三點：性能，集成，和可擴展性。據開發小組人員的簡單測試，原來在SQL Server 2000中建立全文索引需要14天的表，現在只需要幾個小時！幾乎有上百倍的性能提升，只能用「驚異」來形容。其相關的全文檢索語句也有30％～50％甚至更高的性能提高。性能方面的提高得益於全新設計的全文檢索引擎。其中關鍵的一點設計是全文檢索引擎現在使用共享內存和SQL Server 進行數據大規模並發交互，而不是原來基於逐行的方式，使得性能上了好幾個數量級。

除了性能，SQL Server 2005 中的全文索引的集成性也大大加強。在SQL Server 2000 中很難對全文檢索進行備份。一旦有資料庫恢復或移動，你得重新重建索引。對於幾百個GB的資料庫，重建索引幾乎是不能接受的惡夢。現在終於可以和資料庫一起備份和恢復全文索引了。你不再需要在恢復資料庫後重建全文索引了！惡夢終於成為歷史。除了可以備份外，你也可以方便的改變全文索引的磁碟位置。你甚至可以在一個熱備機器上把全文索引建立好，然後 這個索引到生產伺服器上使用。

升級理由八：可用性功能增強
索引聯機操作。除了資料庫鏡像，SQL Server 2005 中可用性還有很多其他提高。索引現在可以使用ONLINE關鍵字進行在線建立或重建或刪除了。它的技術要點是在內存裡面動態生成索引的另一個副本從而不影響原來查詢的進行。一旦索引副本完成操作即替代原來索引成為當前索引。我認為索引聯機操作的意義是很大的，因為很多資料庫系統都有定期調整或維護索引方面的需求。有了2005 你無需擔心業務的正常運行而大膽的對索引進行維護或修改。

頁校驗和。SQL Server 2005中的資料庫頁引入校驗和增強了數據的可靠性。除了原來SQL Server 2000 中已有的TORN_PAGE_DETECTION 外，SQL Server 2005 新增實現了頁的檢驗和（CHECKSUM）。你使用ALTER DATABASE語句的SET PAGE_VERIFY子句即可指定。它的原理是向磁碟中寫入8K數據頁面時，SQL Server計算整個8K頁面內容的校驗和並將該值存儲在頁頭中。再次從磁碟中讀取頁時，SQL Server動態計算讀取到的頁面內容的校驗和，並與存儲在頁頭中的校驗和值進行比較。如果不相等則意味著頁面有物理損壞，需要檢查IO硬體。另外設置檢驗和的另一個好處是還可以在備份和還原操作過程中使用RESTORE VERIFYONLY語句驗證每一數據頁的完整性從而確認備份文件沒有物理損壞。

在線還原。在資料庫的某一部分未恢復前，用戶無法對該部分進行訪問，但可以訪問所有其他數據。SQL Server 2000中如果資料庫在還原或recovery當中，用戶不能訪問資料庫。這樣如果資料庫很大需要rollback或rollforward的事務很多的話，recovery的時間會出奇的長。SQL Server 2005 的在線還原功能使得資料庫在很短的時間內變得可用。

升級理由九：復制增強
SQL Server 2000 中的復制功能已經很好。我這里把復製作為升級的一個理由因為SQL Server 2005在原來的基礎上又增添了不少的功能。如peer-to-peer對等復制，可以在參與者之間相互進行復制，這樣你可以採用對等復制在復制參與者之間建立某種程度的負載平衡。合並復制現在支持通過HTTPS進行數據同步，可以方便建立基於INTERNET 的復制。發布表現在可以使用標準的T-SQL語句如Alter Table等進行結構修改然後被復制而不是僅僅局限於使用sp_repladdcolumn和sp_repldropcolumn存儲過程。在SQL Server 2000 中，僅支持向其他資料庫（如DB2或Oracle）發布數據，而在SQL Server 2005 中，可將Oracle 資料庫直接復制到SQL Server。可以從備份中初始化事務性訂閱而不是僅僅局限於從快照對復制進行初始化，等等……

升級理由十：非同步處理能力
SQL Server 2005 通過引入全新的Service Broker 提供了革命性的非同步處理能力。Service Broker提供了一個功能強大的非同步編程模型。它為資料庫應用程序增加了可靠、可擴展、分布式非同步功能非同步編程，允許程序僅僅在資源可用時才去執行佔用大量資源的任務，以此來縮短響應時間，提高吞吐量。在我看來，Broker的最大好處一是非同步執行能力，提高了可伸縮性，二是可靠執行，三是集成於資料庫中，備份資料庫就備份了broker 的消息隊列。SQL Server 2005 中的查詢通知就是基於Service Broker的應用。你可以使用查詢通知功能來發送一個命令到SQL Server請求在查詢結果發生變化時接收SQL Server的通知。這樣就可以只有在程序以前檢索的結果發生變化時，才需要重新查詢資料庫。一個可以預見的應用是在使用緩存的Web 站點中。Web站點首先發送語句到資料庫伺服器，獲得數據，緩存到本地，然後只有在收到查詢通知的時候才清理緩存，重新查詢數據。這個機制避免了重復輪詢 SQL Server，大大減輕了伺服器的負載，也提高了Web 站點的伸縮性。

因為SQL Server 2005 的Service Broker帶來了資料庫編程非同步處理能力的革命，我把它作為升級的第十個理由。

去網上找找吧，這類的介紹很好找的

4. java.sql.SQLException: ORA-00604: 遞歸 SQL 級別 1 出現錯誤 ORA-01003: 語句未進行語法分析

ORA-00604： 遞歸某個SQL 層時出現錯誤
- initSID.ora中，參數DC_FREE_EXTENTS或ROW_CACHE_ENQUEUES太低。可以根據操作系統和資料庫的情況，適當增加這兩個參數的值，宕下並重新啟動ORACLE.
- 運行超出空間（伴隨ORA-1547錯誤）。這時，要對表空間添加新文件，即增加表空間的大小。
- 達到了MAX_EXTENTS（伴隨ORA-1556錯誤）。如果這樣，就要修改表，允許更多的擴展。請從技術手冊中查找MAX_EXTENTS的最大值。如果已經達到了最大值，必須用compress extents選項，把表卸出（export），再導入（import）資料庫中。

5. oracle中使用sql遞歸算出1加到100的值

declare
iint;
kint;
begin
i:=1;
k:=0;
whilei<=100loop
k:=k+i;
i:=i+1;
endloop;
dbms_output.put_line(k);
end;

上邊是用while循環，下邊這個用for循環

declare
kint;
begin
k:=0;
foriin1..100loop
k:=k+i;
endloop;
dbms_output.put_line(k);
end;

6. Java項目啟動：ORA-00604: 遞歸 SQL 級別 3 出現錯誤

JDBCExceptionReporter] ORA-00604: 遞歸 SQL 級別 3 出現錯誤
ORA-04031: 無法分配 4096 位元組的共享內存 ("shared pool","select /*+ rule */ bucket_cn...","Typecheck heap","kgghteInit")
ORA-00604: 遞歸 SQL 級別 2 出現錯誤
ORA-04031: 無法分配 4096 位元組的共享內存 ("shared pool","select /*+ rule */ bucket_cn...","Typecheck heap","kgghteInit")
11:31:45,625 INFO [STDOUT] 11:31:45,625 WARN [SettingsFactory] Could not obtain connection metadata
java.sql.SQLException: ORA-00604: 遞歸 SQL 級別 3 出現錯誤
ORA-04031: 無法分配 4096 位元組的共享內存 ("shared pool","select /*+ rule */ bucket_cn...","Typecheck heap","kgghteInit")

你的這個欄位是不是BLOB或CLOB類型，並且存了超過4K位元組的內容啊？

還有建議你到SQL最好優化一下，我看你在其他強制索引，但你最好注意ORACLE的開銷策略，SQL里ORACLE有自己的特殊演算法，雖然程序里要求用索引，但ORACLE里不一定會用的，還有SQL最好不要一次關聯太多表，不僅影響效率，還會影響系統的。

7. XML 和資料庫之間的映射有什麼作用

樓主 首先我們應該明白xml的作用：
XML的簡單使其易於在任何應用程序中讀寫數據，這使XML成為數據交換的唯一公共語言，雖然不同的應用軟體也支持其它的數據交換格式，但不久之後他們都將支持XML，那就意味著程序可以更容易的與Windows、Mac OS, Linux以及其他平台下產生的信息結合，然後可以很容易載入XML數據到程序中並分析他，並以XML格式輸出結果。
————————————————————————
由上面我們可以得知，XML成為數據交換的唯一公共語言，異構系統 甚至 異構平台的信息交互 都要靠xml傳輸數據，舉個例子：
.net 開發的系統 和 java開發的系統 如何進行數據交換，如何進行深度整合和互操作，考得就是webservice，而現在webservice數據格式一般都是採用xml的，因為xml是數據交換的事實上的工業標准了，通過它我們可以「穿透那個可親又討厭的防火牆」. 呵呵

數據一般都是從資料庫中取出的吧，所以 研究xml與資料庫數據的互相轉化和映射關系，就顯的非常重要了。

————————————————————————

XML在Web領域已經得到了廣泛的應用，而XML資料庫一直是個研究熱點。各資料庫廠商及研究機構紛紛投入對XML技術的研究及開發。大體上可以把XML資料庫分為兩類：原生XML資料庫(Native XML Database)和使能XML資料庫(Enable XML Database)。而XML數據一般可劃分為粗粒度、中粒度及細粒度三種形式。以文檔為中心的粗粒度形式，一般採用原生XML資料庫，而以數據為中心的細粒度形式一般採用使能XML資料庫。

XML數據是嵌套的樹形結構，而關系資料庫是簡單、平面的二維表結構，結構的差異性，使得在存儲XML數據時需要按一定的映射規則進行轉換，並使能夠恢復到原XML文件。

XML文件物理結構上由多種元素組成，本文的研究只考慮常用的ELEMENT、TEXT、ATTRIBUTE三種元素，採用三個表來保存XML數據。主要思想是把樹結構中的中間節點(非屬性和文本節點)放入mNode(Middle Node)表，葉子節點(屬性和文本節點)放入eNode(End Node)表，另外一個是ePath表，用於保存從根節點到葉子節點的路徑。當然保存多個XML時，我們會引入一個用於保存區分各個XML的表。詳細說明如下：

1) Path(pathID, path)

該表主要保存從根結點到各個葉子結點的所有不同的路徑，在查詢時可滿足類似於Xpat的查詢。

pathID：各不同的路徑標識符，在解析過程中產生。

path：實際路徑名稱。

2)mNode(nodeID, nodeName, parentID, order, pathID)

該表主要通過指定parentID來保存各節點間的父子關系，以保持原XML的樹型結構。

nodeID：節點的唯一標識符，在解析過程中產生。

nodeName：節點的名稱，即XML中的實際名稱。

parentID：父節點的標識符，根節點置為-1。

order：兄弟節點的先後次序。

pathID：從根結點到本節點所走的路徑。

3)eNode(nodeName, nodeValue, parentID, order, type)

該表主要保存屬性及文本節點的值。

nodeName：屬性名，如果是文本節點則取其父節點名。

nodeValue：屬性文本值。

parentID：父節點的標識符。

order：兄弟節點的先後次序。

type：用於區分屬性還是文本的標量。

4轉換方法

從XML到SQL，一般都是採用遞歸演算法，先根遍歷XML樹結構，而從SQL返回到XML時，一般採用隊列生成XML節點。遞歸過程一般要消耗較多的時間和空間，在處理較大結構的XML時，性能上不是很理想。

本模型在XML和SQL中放入一個中間層，該層中主要有根據DTD或Schema生成的一系列Bean、一個操作SQL的模塊、一個操作XML的模塊，另外在此基礎上還可以方便擴展給其他業務邏輯層調用的模塊。結構如下圖所示:

JavaBeans：這里所說的JavaBeans是根據XML 對應的DTD或Schema所產生的有級聯關系的類。通過這些類邏輯上形成一棵XML樹形結構，用於存放實際XML數據。對於如下的一部分DTD：

<! ELEMENT book (title, price, author+)>
<! ATTLIST book year CDATA>
<! ELEMENT title (#PCDATA)>
<! ELEMENT price (#PCDATA)>

我們可以設計一個BookItem類，它包括一個TitleTxt欄位、一個PriceTxt欄位、一個AuthorBean欄位以及一個YearAttr欄位，其中AuthorBean由多個AuthorItem組成，類似的，AuthorItem包含它下面的節點信息。在這個過程中，可以完成ePath表的信息建立。

根據前面的映射模型，對於BookItem類的title欄位，設計如下形式的類結構：

Public Class BookItem(){
Private String titleTxt;
Public setTitleTxt(String title){}
Public getTitleTxt(){}
Public setTitleParentID(int parentID){}
Public getTitleParentID(){}
Public setTitleOrder(){int order}
Public getTitleOrder(){}
…
}

而對於AuthorBean類，類結構設計如下：

Public Class AuthorBean(){
Private Vector beanVector;
Public void add(AuthorItem authorItem){}
Public AuthorItem getByIndex(int index){}
Public int getSize(){}
…
}

從結構上容易看出，代碼量非常大，但由於都是一些get()和set()方法，這些代碼不用通過手工去撰寫，而是根據DTD或Scheme的信息自動生成。在過程①及過程④中調用set()方法，在過程②及過程③中調用get()方法。

XML Operator：該模塊可以支持DOM、SAX解析。根據層次信息依次解析每個節點，此過程中記錄父子節點關系，並且記錄一個節點中所有子節點的先後順序，並設定到Bean中。

SQL Operator：該模塊主要是把Bean中的信息寫入資料庫，以及從資料庫中讀取信息供重組XML。

樓主，希望我的給出信息和資料對你的問題的解決 有所幫助！：-）

8. sql遞歸建立公司結構的方法 下面有錯誤但是不知道錯在哪裡

ORA－00604：遞歸某個SQL層時出現錯誤－initSID．ora中，參數DC＿FREE＿EXTENTS或ROW＿CACHE＿ENQUEUES太低uycg可以根據操作系統和資料庫的情況適當增加這兩個參數的值628宕下並重新啟動ORACLE．－運行超出空間（伴隨ORA－1547錯誤）mq這時，要對表空間添加新文件，即增加表空間的大小ycg－達到了MAX＿EXTENTS（伴隨ORA－1556錯誤）m如果這樣，就要修改表，允許更多的擴展。請從技術手冊中查找MAX＿EXTENTS的最大值。如果已經達到了最大值，必須用compressextents選項28把表卸出（export），再導入（import）資料庫中。

9. Sql server 如何實現遞歸演算法

可去了解一下SQL的CTE演算法，實現遞歸

10. sql 2000 遞歸演算法

select
categoryName

from
表名

where
categoryCode
like
'01%'

order
by
Clevel

具體你01的取值可以通過參數實現