这可能是因为该数据库: 处于可疑模式。 不再存在。 处于单用户模式,并且唯一可用的连接已由其他用户或事物使用。 已被分离。 已设置为 RESTRICTED_USER 状态。 处于脱机状态。 设置为紧急状态。 不具有映射到用户的登录帐户,或者该用户已被拒绝访问。 此外,该登录帐户可能是多个组的成员,且其中一个组的默认数据库在连接时不可用。 SQL Server 2005 在 SQL Server 2005 中,可以使用 sqlcmd 实用程序更改默认数据库。为此,请按照下列步骤 *** 作: 1 单击“开始”,单击“运行”,键入 cmd,然后按 Enter。 2 根据 SQL Server 登录使用的身份验证种类,请使用以下方法之一: 如果 SQL Server 登录使用 Microsoft Windows 身份验证连接到该实例,请在命令提示符处键入以下内容,然后按 Enter: sqlcmd –E -S InstanceName –d master 如果 SQL Server 登录使用 SQL Server 身份验证连接到该实例,请在命令提示符处键入以下内容,然后按 Enter: sqlcmd -S InstanceName -d master -U SQLLogin -P Password 注意:InstanceName 是要连接到的 SQL Server 2005 实例的名称的占位符。SQLLogin 是已删除其默认数据库的 SQL Server 登录的占位符。Password 是 SQL Server 登录密码的占位符。 3 在 sqlcmd 提示符处,键入以下内容,然后按 Enter: Alter LOGIN SQLLogin WITH DEFAULT_DATABASE = AvailDBName 注意:AvailDBName 是可由实例中 SQL Server 登录访问的现有数据库的名称的占位符。 4 在 sqlcmd 提示符处,键入 GO,然后按 Enter。 SQL Server 2000 和 SQL Server 70 在 SQL Server 2000 和 SQL Server 70 中,可以使用 osql 实用程序更改默认数据库。为此,请按照下列步骤 *** 作: 1 在命令提示符处,键入以下内容,然后按 Enter: C:\>osql -E 2 在“osql”提示符处,键入以下内容,然后按 Enter: 1>sp_defaultdb 'user's_login', 'master' 3 在第二个提示符处,键入以下内容,然后按 Enter: 2>go 更简单明了的: 无法打开用户默认数据库,登录失败,这也是SQL Server使用者熟悉的问题之一。在使用企业管理器、查询分析器、各类工具和应用软件的时候,只要关系到连接SQL Server数据库的时候,都有可能会碰到此问题,引起此错误发生的原因比较多,下面我们就来详细分析引起此问题的原因以及解决办法。 一、原因 登录帐户的默认数据库被删除。
一 更改日志 *** 作模式三步走
默认情况下 Oracle数据库采用的是非归档模式 但是 非归档模式不能够防止因物理损坏而导致丢失数据问题 为此数据库管理员可能需要把日志 *** 作模式从非归档模式转换为归档模式 其实 要进行这个转换的话 只需要通过简单的三个步骤即可 不过在进行 *** 作之前 要需要注意 以下的 *** 作都必须要求用户具有数据库管理员的权限 即只有SYSDBA或者SYSOPER身份才能够执行如下的 *** 作
要更改日志 *** 作模式 具体 *** 作步骤如下
第一步 先确定当前的日志 *** 作模式 当数据库管理员更改当前 *** 作日志模式之前 需要先确定一下当前日志 *** 作模式 此时数据库管理员可以查询动态性能视图 来确认当前日志 *** 作模式 如可以利用如下语句来查询我们所需要的信息 动态性能视图中存储著很多数据库运行信息 从中我们数据库管理员可以获取很多有用的信息 如现在要了解当前数据库的日志 *** 作模式 就可以从数据库动态性能视图中获知
第二步 关闭数据库 如果确认数据库当前的日志 *** 作模式为非归档模式 需要把它改为归档 *** 作模式 需要先关闭当前运行的数据库 然后重新装载数据库 需要注意的是 更改日志 *** 作模式只能够在MOUNT状态下进行 因此必须首先关闭数据库 然后重新装载数据库 另外 如果需要更改日志 *** 作模式 那么在关闭数据库时不能够使用SHUTDOWN ABORT命令 SHUTDOWN ABORT命令的作用其实跟KILL进程具有同样的效果 若利用这个命令的话 可能会给数据库带来一些不利的因素 如可能导致文件状态不一致 在数据库正常关闭的时候 数据库会同步校验各个文件 使得重新启动的时候文件时间点一致并且不用进行崩溃修复 而使用这个命令不会进行这个检验 所以 采用SHUTDOWN ABORT命令关闭数据库的时候 可能会导致数据库启动出错 导致已经递交的数据丢失 甚至出现数据库崩溃的噩梦 所以 无论是在更换数据库日志 *** 作模式 又或者其他原因需要关闭数据库的 最好不要采用这个命令 只有在采用其他关闭数据库命令不能够奏效的情况下 才能够使用这个命令 笔者建议通过SHUTDOWN IMMEDIATE命令来关闭数据库
数据库关闭之后 再利用Startup命令 把数据库启动到MOUNT状态 再次提醒一次 只有在Mount状态下才能够更改日志 *** 作模式
第三步 更改日志 *** 作模式 以上准备工作做好之后 就可以利用相关命令来更改日志 *** 作模式 我们可以利用如下命令来进行更改
然后重新打开数据库之后 设置就生效了
二 手工对重做日志文件进行归档
有时候出于某些原因 数据库管理员可能需要手工对重做日志进行归档 在 G以后的版本中 默认情况下 当将日志 *** 作模式从非归档模式转换为归档 *** 作模式的时候 Oracle数据库会在后台自动启动一个ARCH进程 这个进程就是负责重做日志的备份任务 通常情况下 归档模式下 数据库会自动备份重做日志
若需要手工备份重做日志的话 即手工归档 则必须在改变 *** 作日志模式中明确说明 即在上面的命令中 加入MANUAL参数 如果加入这个参数后 则数据库管理员就必须手工执行归档命令 如果数据库管理员没有手工执行归档命令的话 则日志组中的内容就无法被进行覆盖 所以通常情况下 除了一些特殊的需要 如数据库测试 才使用手工归档方式 否则的话 就还是采用自动归档方式更加的合理 值得一提的是 根据笔者了解 这个参数只是一个过渡参数 主要为了跟以前的Oracle数据库版本兼容 估计在不久之后 这个手工归档的参数会取消掉
三 设置归档文件的存储位置
在 *** 作系统管理中 系统管理员往往会重新设置我的文档 IE收藏夹等存储位置 以防止系统奔溃时这些数据的丢失 其实 在Oracle归档日志文件管理中也是如此 当数据库管理员把日志 *** 作模式从非归档模式转换为归档模式时 需要根据实际情况 重新设置归档文件的存储位置
当数据库处于归档模式时 如果进行日志切换 后台进程将自动生成归档日志文件 归档日志文件的默认存储位置为Oracle数据库安装目录下的RDBMS下 而在实际工作中 数据库管理员往往会改变其存储位置 如出于空间的考虑或者安全方面的考虑 会把归档日志存放在数据文件不同的硬盘中 等等
如果需要更改归档日志的 *** 作文件 则需要变更相应的初始化参数 参数Log Archive Dest就是用来控制归档日志的存储路径的 通常情况下 若是没有备用数据库的话 则只需要把归档日志存放到服务器上的独立的硬盘中即可 而不需要进行异地备份 如果需要配置本地归档日志的存储路径 则可以通过以上的初始化参数以及Log Archive Duples_Dest参数 其中前面一个参数用来指定第一个归档日志的位置 第二个参数用来指定第二个归档日志的位置 当分别对以上两个参数进行配置后 数据库系统在进行日志切换时 后台进程就会生成两份完全相同的归档日志 分别存储在上面两个不同的路径中 这里需要强调的一点是 存放在两个不同路径中的归档日志文件是完全相同的 这主要是出于数据安全的需要 一般情况下 只需要一个归档日志即可 若不放心的话 则可以设置多个归档日志存放位置 不过这些归档日志最好能够存放到不同的磁盘上 否则的话 就没有多少的实际意义
除了以上这个配置参数之外 平时工作中 我们还经常会使用Log Archive Dest_N这个参数 这个参数主要用于指定多个归档位置 通常情况下 可以多大十个归档位置 这个参数跟先前提到的两个参数有比较大的不同 数据库管理员要对此有清晰的认识 只有如此 才能够根据自己的需要 选择合适的初始化参数 他们的差异主要有以下几点
一是不带N的初始化参数(即前面的两个参数)只能够用来配置本地归档位置 而后面谈到的这个参数这可以用来配置本地归档位置与远程归档位置 也就是说 如果数据库管理员要把归档日志文件保存在网络上的其它主机中时 就必须利用后面的参数进行配置 这个区别是几个参数之间最大的差异 不过由于网络传输等方面的限制 笔者并不建议把归档日志保存在其它主机上 而是建议在数据库服务器中增加一块独立的硬盘用来保存归档日志文件即可 因为硬盘之间数据的复制要比网络传输要快的多 这可以避免重做日志归档时对网络资源过多的占用 从而降低网络的性能
二是前面两个参数只能够配置两个不同的归档日志位置;而后面一个参数则可以配置多大十个归档日志文件位置 这是两者数量上的差异 不过没什么作用 对于大部分企业来说 可能两个归档日志文件存放位置已经可以满足他们的需求了 另外一个小的差异就是 后面这个参数不能够跟前面两个参数共存 为此 当使用后者这个参数时 就需要先把前面两个参数禁用掉 因为数据库默认情况下 是启动第一个初始化参数的
三是具体的配置也有所不同 利用后者参数指定归档日志存储位置时 如果配置本地归档位之 则需要指定Location选项;如果是配置远程归档日志位置时 则就需要制定Service选项 这个选项主要用来指定远程数据库的网络服务名 通常情况下 数据库管理员可以同时配置本地归档位置与远程归档位置
lishixinzhi/Article/program/Oracle/201311/18259
麻烦了,很多DBA不太清楚,数据库的日志装的其实是真正的数据(归档前改变的数据),所以日志文件也是非常重要的。
至于有些数据库的日志文件过大,主要是DBA没有正确的对数据库进行调优设置造成的。
下面的方法也许对你是有用的。
0备份数据文件'xxzx_discuz_LogMDF'
1新建一个同名的数据库'xxzx_discuz'
2再停掉sqlserver服务(注意不要分离数据库)
3用原数据库的数据文件'xxzx_discuz_LogMDF' 覆盖掉新建的数据库
4再重启sqlserver服务
5此时打开企业管理器时会出现置疑,先不管,执行下面的语句(注意修改其中的数据库名)
6完成后一般就可以访问数据库中的数据了。这时,数据库本身一般还有问题,解决办法是:利用数据库的脚本创建一个新的数据库,然后通过DTS将数据导进去就行了
SQL代码
use master
go
sp_configure 'allow updates',1 reconfigure with override
go
update sysdatabases set status =32768 where name='置疑的数据库名'
go
sp_dboption '置疑的数据库名', 'single user', 'true'
go
dbcc checkdb('置疑的数据库名')
go
update sysdatabases set status =28 where name='置疑的数据库名'
go
sp_configure 'allow updates', 0 reconfigure with override
go
sp_dboption '置疑的数据库名', 'single user', 'false'
go
特别注意最后一步中的说明“这时,数据库本身一般还有问题,解决办法是:利用数据库的脚本创建一个新的数据库,然后通过DTS将数据导进去就行
1,默认情况下,oracle的日志文件记录在$ORACLE/rdbms/log目录下
[plain]viewplaincopy
[oracle@oraclelog]$pwd
/home/oracle/oracle/proct/1020/db_1/rdbms/log
日志文件为(alert_log):
[plain]viewplaincopy
[oracle@oraclelog]$ll
总计848
-rw-rw-r--1aaaaaa96206-2015:57alert_TESTDBlog
2,如果不是在默认位置,则可通过sql查询日志文件位置:
[plain]viewplaincopy
SQL
NAMETYPE
VALUE
background_mp_deststring
/home/oracle/oracle/admin/TESTDB/bmp
core_mp_deststring
/home/oracle/oracle/admin/TESTDB/cmp
user_mp_deststring
/home/oracle/oracle/admin/TESTDB/ump
其中background_mp_dest的value值即为日志文件存放位置
四 如何利用LogMiner分析Oracle 的日志文件 虽然说LogMiner是Oracle i才推出来 但我们同样可以用它来分析Oracle 的日志文件 只不过稍微麻烦了一点 并且有一定的限制 下面是具体做法 我们首先复制Oracle i的$ORACLE_HOME/rdbms/admin/dbmslmd sql脚本到Oracle 数据库所在主机的同样目录 这个脚本用于创建dbms_logmnr_d包(注意 Oracle i中还将创建dbms_logmnr包) 如果是 脚本名字为dbmslogmnrd sql 然后在Oracle 的数据库上运行这个脚本 之后使用dbms_logmnr_d build过程创建字典信息文件 现在我们就可以把Oracle 的归档日志连同这个字典信息文件复制到Oracle i数据库所在的主机上 之后在Oracle i数据库中从上面分析过程的第三步开始分析Oracle 的日志 不过 dbms_logmnr start_logmnr()中使用的是Oracle 的字典信息文件 按照我前面所说的那样 如果不是字典文件 我们则可以直接将Oracle 的归档日志复制到Oracle i数据库所在主机 然后对它进行分析 其实这里涉及到了一个跨平台使用LogMiner的问题 笔者做过试验 也可以在Oracle i中来分析Oracle i的日志 但这些都是有所限制的 主要表现在 LogMiner所使用的字典文件必须和所分析的日志文件是同一个数据库所产生的 并且该数据库的字符集应和执行LogMiner数据库的相同 这很好理解 如果不是同一个数据库所产生就不存在对应关系了 生成日志的数据库硬件平台和执行LogMiner数据库的硬件平台要求一致 *** 作系统版本可以不一致 笔者做试验时(如果读者有兴趣可以到我网站上下载试验全过程 因为太长就不放在这里了) 所用的两个数据库 *** 作系统都是Tru UNIX 但一个是 V A 另一个则是V F 如果 *** 作系统不一致则会出现下面的错误 ORA : file /data /cyx/logmnr/arch_ _ arc cannot be openedORA : cannot open archived log /data /cyx/logmnr/arch_ _ arc ORA : skgfifi: file header information is invalidORA : at SYS DBMS_LOGMNR line ORA : at line 五 分析v$logmnr_contents 前面我们已经知道了LogMiner的分析结果是放在v$logmnr_contents中 这里面有很多信息 我们可以根据需要追踪我们感兴趣的信息 那么我们通常感兴趣的有哪些呢? 追踪数据库结构变化情况 即DDL *** 作 如前所述 这个只有Oracle i才支持 SQL> select timestamp sql_redo from v$logmnr_contents where upper(sql_redo) like %CREATE% ;TIMESTAMP SQL_REDO : : create table t (c number); 追踪用户误 *** 作或恶意 *** 作 例如我们现实中有这样需求 有一次我们发现一位员工通过程序修改了业务数据库信息 把部分电话的收费类型改成免费了 现在就要求我们从数据库中查出到底是谁干的这件事?怎么查?LogMiner提供了我们分析日志文件的手段 其中v$logmnr_contents的SESSION_INFO列包含了下面的信息 login_username=NEW_ client_info= OS_username=oracle Machine_name=phoenix OS_terminal=ttyp OS_process_id= OS_program name=sqlplus@phoenix (TNS V V ) 虽然其中信息已经很多了 但在我们的业务数据库中 程序是通过相同的login_username登录数据库的 这样单从上面的信息是很难判断的 不过我们注意到 因为公司应用服务器不是每个人都有权限在上面写程序的 一般恶意程序都是直接通过他自己的PC连到数据库的 这就需要一个准确的定位 IP追踪是我们首先想到的 并且也满足我们的实际要求 因为公司内部IP地址分配是统一管理的 能追踪到IP地址我们就可以准确定位了 但从面的SESSION_INFO中我们并不能直接看到IP 不过我们还是有办法的 因为这个SESSION_INFO里面的内容其实是日志从V$SESSION视图里提取的 我们可以在生产数据库中创建一个追踪客户端IP地址的触发器 create or replace trigger on_logon_triggerafter logon on databasebegin dbms_application_info set_client_info(sys_context( userenv ip_address ));end;/现在 我们就可以在V$SESSION视图的CLIENT_INFO列中看到新登录的客户端IP地址了 那么上面的提出的问题就可以迎刃而解了 假如被更新的表名为HMLX 我们就可以通过下面的SQL来找到所需信息 SQL > select session_info sql_redo from v$logmnr_contents where upper(operation) = UPDATEand upper(sql_redo) like %HMLX% /SESSION_INFO SQL_REDO login_username=C client_info= OS_username=sz xjs chengyx Machine_name=GDTEL\SZ XJS CHENGYXupdate C HMLX set NAME = free where NAME = and ROWID = AAABhTAAFAAABRaAAE ; lishixinzhi/Article/program/Oracle/201311/17810
以上就是关于如何查看sql数据库 *** 作日志全部的内容,包括:如何查看sql数据库 *** 作日志、配置归档日志,让数据库管理更加顺畅、sql数据库日志文件等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)