㈠ oracle資料庫連接信息的初始用戶名和口令是什麼啊
默認用戶有這么幾個,system,sys,scott,hr 。
system的默認密碼是 manager 。
sys的默認密碼是 change_on_install 。
使用sys或者system 用戶登錄以後,使用如下命令解鎖：
alter user scott identified by tiger account unlock ；
alter user hr identified by hr account unlock ；
其中scott / tiger ，hr / hr 是用戶名密碼。
㈡ oracle導出資料庫口令
口令就是你要導出的對象所屬用戶的賬號密碼。例如，你要導出scott用戶下的數據，我們已知scott的密碼為tiger，所以可以這樣：
exp scott/tiger file=/root/scott_exp.dmp log=/root/scott_exp.log
同樣，imp也是一樣
具體你可以用命令
exp help=y和imp help=y來看到它們的參數和說明。
㈢ oracle 11g對管理口令的建議標准時什麼
這個標準是： 你輸入口令時，密碼的組合需要含有如下：小寫字母、大寫字母、數字、下劃線，如果你的口令含有以上4項，則OK
㈣ Oracle資料庫
希望這些內容能夠幫助他們提高的安全性。
一、 鎖定不用的帳戶。
在Oracle安裝的時候，會自動建立幾個默認的資料庫伺服器帳戶。當安裝完成後，系統會自動把某些帳戶鎖定或者設置為過期;但同時也會打開一些有用的帳戶，如SYS、SYSTEM、SYSMAN等等。如果安裝了資料庫實例，可能還會建立scott帳戶。為了的安全性考慮，我們最好能夠把一些不用的帳戶鎖定掉。一般來說，若是系統提供的帳戶，我們只需要保留SYS、SYSTEM、SYSMAN這三個用戶名即可，其他的系統自建的用戶名可以鎖定掉。
另外，在資料庫維護中，我們還會建立自己的管理員帳戶。如筆者在維護資料庫系統的時候，就不喜歡用系統提供的管理員帳戶。而是會先利用他們的帳戶登陸進去，然後建立自己喜歡的用戶名與密碼。所以，當資料庫系統理有你前任資料庫管理員留下來的用戶名而你又不想用的時候，請各位高抬貴手，及早把它鎖定掉。這可以提高資料庫的安全性。可惜的是，筆者有時候給客戶進行資料庫有償維護的時候，發現資料庫中有很多莫名其妙的管理員帳戶。問他們資料庫管理員這些帳戶有什麼用時，他們說是前任留下來的，他們也不知道。對於這些帳戶，筆者的建議是，盡快的把他們鎖定掉或者過期掉。不然的話，對於Oracle系統來說，是一顆定時炸彈。一旦爆炸，就會給這個資料庫帶來不可換回的損失。二、 實施口令管理。
這准確來說，不是筆者的建議，而是Oracle官方的建議。我在參加Oracle培訓的時候，他們的教授就跟我們說，應該將資料庫所提供的基本口令管理准則，如口令長度歷史紀錄、復雜性等等，應用於所有的用戶密碼中，並要求所有的管理員帳戶養成定期更改密碼的習慣。
依賴於密碼管理的資料庫系統來說，需要保證密碼在任何時候都是保密的。可是在實際工作中，密碼可能會泄露，如在輸入密碼的時候被人看到或者被人利用密碼竊取工具竊取到密碼等等。故為了更好的控制資料庫的安全，中通過概要文件來保障資料庫口令的安全。這可以說是的一個獨創的功能了。
具體的來說，Oracle在口令管理上，有如下規則。
1、口令歷史。這跟微軟操作系統中的口令歷史一致。主要是用來指定在一個時間間隔內用戶不能使用相同的密碼。我們可以利用CREATE語句創建一個用戶概要文件，雖然利用REUSE_TIME與REUSE_MAX參數指定間隔天數。TIME參數用來指定在多久後可以採用相同的密碼;而MAX參數則指定，在可以再次使用當前口令之前，用戶必須改變該口令的次數。
2、口令的期限。若一個密碼時間越長，其泄露的幾率越長。最理想的狀態是，每用過一次後，就修改一次密碼。但是，這顯然不怎麼容易實現。所以，我們需要根據一定的情況，設置一個密碼有效的最長期限。當這個期限過後，原來的密碼就失效，用戶必須重新修改密碼。我們可以利用CREATE語句為某一個用戶創建一個概要文件，然後利用LIFE?_TIME參數指定口令的最長有效時間。當然，也可以為到期的密碼指定延長期。當用戶的口令到期後，用戶第一次登陸資料庫的時候，用戶需要輸入延長期。在這個延長期內，用戶仍然可以使用原有的密碼，只是每次登錄資料庫，系統都會提醒用戶修改密碼，直到延長期結束。當延長期滿後，用戶必須更改原有的口令。否則的話，系統會一直提醒用戶更改密碼，而拒絕登陸系統。另外，口令的期限往往跟上面的口令歷史一起使用，從而把密碼的安全性提高到一個新的層次。
3、密碼的復雜性管理。我們都知道，純數字的密碼要比數字、字元混合的密碼好破解的多。故為了加強用戶名密碼的安全性，設置一定的復雜性密碼管理規則是必須的。系統中，提供了很多的密碼復雜性檢查。如可以規定密碼的最小長度;可以設置密碼不能與用戶名相同;可以規定密碼中必須包含字元、數字、標點符號等等;還可以設定密碼不能為簡單的單詞以及密碼的前面幾個字元不能夠相同等等。通過這些復雜性管理，可以最大程度的保障密碼的安全性。如此的話，若想要通過數字字典破解密碼的話，難度就會比較大。不過，密碼雖然復雜了，但是用戶最好不要隨便拿張紙記一下，這樣的話，密碼仍然容易泄露。最好把密碼記熟了，然後把紙撕掉或者燒掉，以確保密碼不會被泄露。
三、 帳戶自動鎖定。
我們在利用銀行卡帳戶的時候，當密碼輸入錯誤超過一定的次數時，這卡就會被鎖住。其實，在中，也可以實現這個目的。當某個管理員帳戶，或者普通的帳戶，其失敗的登陸次數超過了我們指定的次數時，伺服器就會自動鎖定那個用戶帳號。
一般來說，我們只需要給管理員帳戶設置自動鎖定策略即可。因為相對於普通用戶來說，由於其不怎麼熟悉操作，所以密碼輸入錯誤的幾率會比較高。若我們為他們設置密碼鎖定策略的話，那我們很大一部分工作就是給他們進行解鎖。所以，沒有特殊必要的話，不要給普通帳戶設置自動鎖定策略，或者說，至少要把這個密碼輸入錯誤次數設置的高一點。
另外，若是前台應用程序直接連接到資料庫的話，也會有用戶名與密碼。這個用戶名與密碼筆者建議是不要設置密碼鎖定策略，否則的話，我們維護起來會很麻煩。
四、 合理分配終端用戶的許可權。
終端用戶就是企業員工實際用的帳戶。針對普通員工的許可權控制，一般有兩種方式。一是通過前台的應用軟體來控制;二是通過資料庫的用戶許可權來實現。
如果我們是利用資料庫自身的許可權管理器來管理帳戶許可權的話，則我們需要考慮對終端用戶進行分組，然後為這些用戶組創建不同的角色。資料庫管理員可以先給每個角色賦予必要的許可權，然後再將這些角色賦予相應的用戶組。也就是說，我們不建議直接給用戶賦予相關的許可權，而是通過角色與組來管理資料庫的訪問許可權。在特殊的情況下，如某個許可權只有一個特定的帳戶具有時，則可以直接把許可權賦予這個帳戶。否則的話，我們不建議給用戶直接賦予許可權。
㈤ oracle創建資料庫後的口令管理如何設置
normal 、sysdba、 sysoper 、sys,sysdba,dba概念—區別
sys和system用戶的區別
【system】用戶只能用normal身份登陸em。
【sys】用戶具有「SYSDBA」或者「SYSOPER」許可權，登陸em也只能用這兩個身份，不能用normal。
「SYSOPER」許可權，即資料庫操作員許可權，許可權包括：
打開資料庫伺服器 關閉資料庫伺服器
備份資料庫 恢復資料庫
日誌歸檔 會話限制
「SYSDBA」許可權，即資料庫管理員許可權，許可權包括：
打開資料庫伺服器 關閉資料庫伺服器
備份資料庫 恢復資料庫
日誌歸檔 會話限制
管理功能 創建資料庫
normal 、sysdba、 sysoper有什麼區別
normal 是普通用戶
另外兩個，你考察他們所具有的許可權就知道了
sysdba擁有最高的系統許可權
sysoper主要用來啟動、關閉資料庫，sysoper 登陸後用戶是 public
sysdba登陸後是 sys
SQL> conn / as sysdba
已連接。
SQL> grant sysoper to test;
授權成功。
SQL> conn test/test as sysoper;
已連接。
SQL> show user
USER 為"PUBLIC"
SQL> conn test/test as sysdba
已連接。
SQL> show user
USER 為"SYS"
SQL>
dba和sysdba的區別
dba、sysdba這兩個系統角色有什麼區別呢
在說明這一點之前我需要說一下oracle服務的創建過程
·創建實例
·啟動實例
·創建資料庫(system表空間是必須的)
啟動過程
·實例啟動
·裝載資料庫
·打開資料庫
sysdba，是管理oracle實例的，它的存在不依賴於整個資料庫完全啟動，
只要實例啟動了，他就已經存在，以sysdba身份登陸，裝載資料庫、打開資料庫
只有資料庫打開了，或者說整個資料庫完全啟動後，dba角色才有了存在的基礎！
㈥ 如何應對被公開的Oracle口令加密演算法
由於Oracle資料庫被廣泛應用，其口令加密演算法也是備受關注。最早在1993年comp．databases．oracle．server新聞組中有人披露了加密演算法的大部分細節。十年後，一本名為《Special Ops Host and Network Security for Microsoft， Unix and Oracle》的書中補全了演算法最重要的一個環節——DES演算法的KEY。至此，口令加密演算法已無秘密可言。接踵而來的是互聯網上出現多個了Oracle口令破解工具。Oracle在2007年推出的最新版本11g中，使用了新的更安全的加密演算法，但是新演算法的細節很快又在互聯網上被公開。為提供兼容，11g版本保留了11g以前版本使用的加密口令，利用這一漏洞仍然可以對11g版本的加密口令進行破解。
到底怎樣才能保證資料庫口令的安全呢？本文首先介紹Oracle資料庫各版本口令加密演算法的內容，然後針對演算法重點介紹加強資料庫安全性的應對措施。
口令加密演算法
從Oracle7到Oracle 10gR2，使用DES演算法對口令進行加密。對演算法進行分析，可以得出如下結論：口令不區分大小寫，任意大小寫組合均可登錄；由於只使用固定KEY，只要用戶名和口令相同，在任一DB中存放的加密口令都相同；由於採用了用戶名和口令串接的方式，所以用戶aaa、口令bbbccc的加密值與用戶aaabbb、口令ccc完全相同。
Oracle 11g版本的加密口令存放在SYS．USER$表中的SPARE4列中，而PASSWORD列中仍保留以前版本加密口令。由於客戶端計算加密口令需要用到SALT，在建立連接時，伺服器端將SALT明文傳送給客戶端程序。Oracle 11g中新的口令加密演算法中區分大小寫；由於加入了隨機數SALT，兩個不同用戶的口令即便完全相同，計算得到的SHA1的散列值也不同；不同DB中相同用戶相同口令，SHA1散列值也可能不同。
目前，大多數破解工具的工作方式是得到加密口令後，對每一個可能的口令進行加密計算，比較計算結果而確定是否正確。由此，抵禦口令破解可以從三個方面著手：防止加密口令外泄；在加密口令落入黑客手中後，口令也是不可破解的，或盡量增加破解的時間；即便是口令被破解，也是無用的，不能存取資料庫。
防止加密口令泄露
1．應用「最少許可權」原則，盡量限制可存取加密口令用戶的人數
在資料庫中檢查具有存取SYS.USER$或DBA_USERS許可權的用戶，並從不需要的用戶中收回許可權。但是操作並不簡單，這也是資料庫管理工作的特點。每一廠商的軟體中都實現了SQL標准之外的擴充，並且每一版本都有差異。限於篇幅，不可能對所有本文中建議的措施進行詳細的解釋說明，僅以此處檢查許可權為例展示DBA工作的復雜性。本文中如未說明，則默認版本為11g。應用於11g以前版本時，請讀者確認是否需要修改。
檢查許可權主要的工具是數據字典視圖（也可以直接存取SYS用戶的基表，但基表的定義沒有公布，官方不提供技術支持）。視圖DBA_TAB_PRIVS存放了資料庫中數據對象上的授權信息。假定用戶A1和A2可以存取SYS．USER$表，檢查在SYS用戶USER$上有存取許可權的用戶，可執行如下語句：
SELECT GRANTEE FROM DBA_TAB_PRIVS WHERE TABLE_NAME=『USER$』；
我們已經知道用戶A1和A2，都可以存取SYS.USER$表，但為什麼在上面查詢結果中沒有出現呢？這是因為在Oracle的許可權管理中，對一個表的存取許可權還可以通過系統許可權或角色賦予，而DBA_TAB_PRIVS中僅列出了直接的對象許可權的授予信息。對於SYS．USER$表而言，系統許可權SELECT ANY DICTIONARY和角色DBA都包含了這一表的存取許可權。所以完整列出所有可存取這一表的用戶應增加下面兩條查詢語句的結果：
SELECT GRANTEE FROM DBA_SYS_PRIVS WHERE PRIVILEGE＝『SELECT ANY DICTIONARY』；
SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE＝『DBA』；
通過上面的查詢語句，還是會遺漏某些用戶。如果把DBA角色授權給另一角色Admin，然後又將Admin角色授權給另一用戶NEWU，則此用戶可存取SYS.USER$表，但在上述三個查詢中並沒有直接列出NEWU的名字（角色Admin會出現在第三個查詢語句的結果中）。
顯然，Oracle的授權構成了一棵樹，完整的信息需要一段PL/SQL程序來完成。（對於11g以前版本，還需要檢查對DBA_USERS視圖有存取許可權的用戶和角色。SELECT_CATALOG_ROLE角色如被授權，則可以存取所有數據字典視圖，但不能存取SYS的基表。）
2．設定對加密口令存取的審計
如果當前系統中只有SYSDBA可以存取USER$，則一個變通辦法是審計SYSDBA的所有操作，其中也包括對USER$的存取。設置初始化參數audit_sys_operations ＝TRUE，重新啟動資料庫後激活對SYSDBA操作的審計。
審計文件的存放位置為：
11g版本中為：$ORACLE_BASE/admin/SID/ amp／ *．aud
11g以前版本為： $ORACLE_HOME/rdbms/audit/ *．aud。
嚴格限制和監視SYSDBA用戶活動的最好辦法是使用Oracle Database Vault組件。
3．在操作系統級限制對資料庫數據文件的存取
SYSDBA用戶的加密口令存放在$ORACLE_HOME/dbs下的口令文件orapw〈SID〉中。SYS．USER$表同樣需要在數據文件中存放，多數為SYSTEM表空間的第一個數據文件中。此外，EXPORT文件、REDOLOG文件以及TRACE文件中都可能出現加密口令。需要嚴格限制上述文件的存取許可權。
4．防止網路竊聽
在建立連接時，客戶端需要向伺服器端傳送用戶名和口令，並且伺服器端與客戶端需要相互發送這次會話使用的SESSION KEY。Oracle採用Diffie-Hellman KEY交換演算法和自己開發的O3LOGON協議完成上述任務。演算法的細節同樣已在互聯網上被公開。建立連接時上述信息如果被截獲，同樣可以被用來破解口令。更為嚴重的是，如果黑客事先已經獲得加密口令，結合SESSION KEY的信息，則不需要任何破解，執行簡單還原運算就可算出口令明文。
另外，設計SID時不要使用如ORCL、TEST、PROD等常用名字，設定PORT號為遠遠大於1521的數，都可以增加黑客SID掃描的難度和時間。
5． 刪除舊版的加密口令
存放在Oracle 11g資料庫中的以前版本的加密口令是口令破解工具的一個突破口。在沒有兼容性限制的系統中，可以考慮從系統中刪除舊版口令，從而增加破解難度。
具體操作如下：
在SQLNET.ORA中增加一行：SQLNET.ALLOWED_LOGON_VERSION=11（Oracle手冊中格式介紹有錯誤，不能加括弧：…＝（11）），指定最低版本。
以SYSDBA登錄後，執行以下語句，刪除舊版口令。
update sys.user$ set password＝NULL；
delete from user_history$；
commit；
設置修改後，基於OCI的工具如SQLPLUS、10gR1和10gR2版本都可以正常登錄，而JDBC type-4 則只有11g版本才允許登錄。
提高口令強度
1．禁止使用預設口令，禁止與用戶名同名的口令，禁止字典詞彙的口令
Oracle 11g中提供一個視圖DBA_USERS_WITH_DEFPWD，可以方便地查出系統中使用預設口令的所有用戶，不足的是還有不少遺漏。讀者可以在互聯網找到預設口令的列表，雖然是非官方的，但是比DBA_USERS_WITH_DEFPWD使用的官方的列表更全。破解工具附帶的詞彙表有的包括了大型英文詞典中全部詞彙，並支持詞彙與「123」之類的常用後綴進行組合。需要注意的是，有的詞彙表中已經出現了「zhongguo」這樣的字元串，所以漢語拼音組成的口令也是不安全的。檢查系統中是否存在弱口令的最常用方法就是使用前述口令破解工具進行攻擊。
2．規定口令最小字元集和口令最短長度
口令字元集最小應包括字母、數字和特殊符號，口令長度最短應不少於8位，對於安全性要求高的系統，最短長度應為12位以上。同樣，問題的關鍵在於DBA指定初始口令以及用戶修改口令時保證不違反上述這些規定。每一用戶都對應一個Profile，如在Profile中指定口令驗證函數，則每當創建或修改口令時，會自動檢查是否滿足驗證程序中所設定的條件，如果不滿足，則口令修改失敗。對口令明文進行檢查，顯然要比對加密口令破解效率高。此外，口令創建之時進行檢查可以及時封殺弱口令，不給黑客留下破解的窗口。
指定口令驗證函數的語句為：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION 口令驗證函數名；
上例中，為「DEFAULT」 Profile指定了驗證函數。對用戶進行分類後，應當為每一類用戶分別創建自己的Profile，而不是全部使用DEFAULT。關閉口令驗證函數的語句為：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL；
在$ORACLE_HOME/rdbms/admin/下，腳本文件UTLPWDMG.SQL提供了示例的口令驗證函數，執行這一腳本，將創建一名為VERIFY_FUNCTION的函數( Oracle 11g中，增加新函數verify_function_11G )。這一函數可以對口令長度是否同時出現了字母數字元號進行檢查，檢查是否與用戶名同名，也檢查口令是否是幾個最常用的詞彙，如welcome、database1、account1等。最後，口令修改時檢查新舊口令是否過於相似。讀者實際使用時應該根據系統需要對這一函數進行必要的修改和擴充。
3．使用易記憶的隨機口令限定口令長度後，如果口令沒有規律很難記憶，則用戶會採用他們自己的方式記住口令，大大增加了遭受社會工程攻擊的可能性。DBA需要幫助用戶設計一個容易記憶而又不易破解的口令。一個簡單易行的方法是找用戶非常熟悉的一個句子，如One world One dream，然後將每一個空格替換為數字或符號：One3world2One1dream#。
定期更換口令
抵禦口令破解要從多方面著手
資料庫中存在多種許可權用戶，各種授權用戶構成一棵樹
應對口令泄露或被破解的措施是強制定期更換口令，設定口令重復使用限制，規定封鎖口令的錯誤次數上限及封鎖時間。即便是加密口令落入黑客手中，在被破解之前或入侵之前，修改了口令，則口令破解變得毫無意義。為了方便記憶，一般用戶有重新使用之前過期口令的傾向，如果對重用不加控制，則定期更換口令將失去意義。上述對口令的管理仍然是通過Profile完成：
ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 30
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME 365
PASSWORD_REUSE_MAX 0
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME UNLIMITED
PASSWORD_VERIFY_FUNCTION my_verify_function;
上面語句制定的口令管理政策為：口令的有效期為30天，隨後有7天的寬限期，寬限期後口令「過期」，必須更改口令後才能登錄。只有經過365天後才能重新使用以前的口令。在連續10次輸入口令錯誤後，賬號被封鎖，設定不自動解鎖，必須由DBA手動解除封鎖。口令驗證函數為my_verify_function。
Oracle 11g以前版本，預設設置中沒有設定口令的有效期，而在Oracle 11g中預設設置有效期為180天。程序中直接寫入口令的應用在升級到11g時一定要注意有效期問題，避免半年後應用突然無法自動運行。另外，口令的有效期對SYS用戶不起作用，DBA一定要主動定期更換口令。
另外一個措施是對登錄資料庫伺服器的主機進行限定，如指定網段或指定IP地址。進一步限定客戶端允許執行的程序，如對非本地登錄禁止使用SQLPLUS，只允許執行某特定應用。
認真實施本文中給出的措施後，可以很有效地防止口令被破解。然而我們的目的是提高資料庫系統的安全性，而不僅僅是保證口令不被破解。資料庫系統安全的任何一個環節出現問題，都會導致前功盡棄。黑客的目的是入侵系統盜竊數據，是不會按常理出牌的，會嘗試各種手段方式，如社會工程、安全漏洞、物理入侵等等，而不會執著地在口令破解上與我們較勁。這一點需要我們經常提醒自己，從而切實保證資料庫系統安全。
TechTarget中國原創內容
㈦ Oracle 11g安裝管理口令應該填什麼
應該填寫登陸資料庫的密碼。