㈠ 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安装管理口令应该填什么
应该填写登陆数据库的密码。