存储过程重建方法
⑴ oracle存储过程失效重启后恢复正常
根据oracle数据库的特点和提供的工具,主要方法有以下几种方法:
利用逻辑备份使用import工具丢失数据的表
利用物理备份来通过还原数据文件并进行不完全恢复
利用dbms_logmnr包从redo log文件中恢复
利用flashback特性恢复数据
前提
为了方便使用方法的介绍,上述恢复方法都将基于以下场景进行:系统管理员在前一天晚上11点用export对数据库做了全库逻辑备份,然后对所有数据文件进行了热备份。第二天上午10点,系统管理员在修改表TFUNDASSET的数据时,由于修改语句的条件写错了,导致一批记录(几千条)的ztm字段被修改成了错误的值,而且已经提交。这个表是资产表,相对而言数据变化不频繁。
一、利用逻辑备份使用import工具恢复丢失的数据
export/import是oracle提供的用于对数据库进行逻辑备份的工具。该工具适用于备份那些数据量不大、业务量不多的数据库系统。因为如果在前一天晚上11点用export做了逻辑备份,那么当今天上午10点数据库意外崩溃时,从备份起到数据库崩溃的这段时间里的数据修改操作(包括DDL和DML)都会丢失。如果丢失数据内的表上的数据是相对比较稳定,也就是说该表上基本没有DML操作,例如标准代码表、分区表里的历史数据,那么采用import来导入该表可以比较完整的恢复数据。如果该表是经常变化的业务表,那么这些丢失的数据只能根据业务情况从纸质记录恢复,或者其他途径恢复。
▲示例如下:这个表是一个资产表。相对来说,今天系统运行中修改的数据较少,丢失的数据量可以承受或者可以从别的途径恢复。那就可以用import来恢复。
方法一:
1、把这个表的数据备份到另一个表:
.png
2、删除该表的记录:
.png
3、执行下面的命令:
.png
这个命令中在关键字tables中指定需要导入的表名字,ignore=y表示忽略表已经存在的错误。
4、导入结束后,检查表中的记录,并用适当的方法恢复当天的修改。
方法二:
1、 把需要恢复的表导入到另一个用户下面:
.png
2、检查数据以后,把原表记录删除:
.png
3、然后从另一用户表中插入回去:
.png
4、 数据量比较大时可以采用如下方法:
.png
二、利用物理备份来通过还原数据文件并进行不完全恢复
如果数据库运行在归档模式下,那么可以通过使用以前的数据文件备份进行还原,然后利用归档日志进行前滚,直到回滚到错误操作的时间点前,然后重置日志文件打开数据库。
可以通过下列方法确认是否是运行在归档模式:
.png
如果是如上所示,那么就是运行在归档模式了。
▲假定在前一天晚上11点做了全库物理备份,那么可以考虑如下恢复:
1、关闭数据库:
由于数据库的不完全恢复必须在一个关闭的数据库上实施,利用一个旧的数据库的备份还原,然后用日志根据需要逐步前滚,而不能还原一个新的备份,再回退到某个时间点。
通知各客户端数据库将关闭,然后发出:
.png
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
2、确定错误操作的时间:
可以根据操作员的估计来确定不完全恢复需要前滚停止的时间,也可以利用LogMiner来分析日志文件(这个工具将在后面介绍),找出错误操作的准确时间。
3、还原数据文件:
先对当前的数据库文件进行备份,然后再用以前的最近一次备份覆盖现有数据文件。注意:不覆盖现有的控制文件。
4、基于时间点恢复,启动数据库到装配状态:
.png
这样数据库就恢复到了2015年10月20日的9点58分零秒。
然后再利用业务资料补充这段时间内的数据。
三、利用dbms_logmnr包从log文件中恢复
这个包是由Oracle提供,与dbms_logmnr_d包配合使用可以方便地分析联机日志文件和归档日志文件,从这些日志文件中提取出所有对数据库的更改操作。
在使用这个包之前,需要先做一些设置和修改:
1、打开initorcl.ora,修改初始化参数utl_file_dir,设置dbms_logmnr_d包将要使用的数据字典文件的放置目录。
.png
然后重启数据库使参数生效。
2、以sys用户连接到数据库执行dbmslmd.sql脚本重建dbms_logmnr_d这个包。
应用Logminer分析重做日志文件的操作主要有以下步骤:
● 使用dbms_logmnr_d里的存储过程build创建一个外部数据字典文件;
● 使用dbms_logmnr里的存储过程add_logfile添加要分析的日志文件;
● 使用dbms_logmnr里的存储过程start_logmnr启动分析;
● 查询与dbms_logmnr相关的几个视图来获取日志文件内容;
● 使用dbms_logmnr里的存储过程end_logmnr结束分析。
▲下面详细讲述使用的过程
1、使用dbms_logmnr_d里的存储过程build创建一个外部数据字典文件:
.png
2、使用dbms_logmnr里的存储过程add_logfile添加要分析的日志文件到待分析文件列表:
.png
如果没有运行在归档模式,那么由于重做日志文件的循环使用可能导致日志文件被覆盖而无法获取到所要寻找的恢复条目。如果运行在归档模式,则可以通过查看$ORACLE_HOMEadminorclbmp目录下的alert_orcl.log里日志文件归档的时间和错误操作的时间来确定加入哪些归档日志文件到待分析的文件列表中去。
.png
注意:执行以上过程时logfilename参数需要写日志文件的全路径,否则会报错。重复以上操作直到把所有需要分析的文件都加到列表中去。这样就可以启动进行分析。
3、使用dbms_logmnr里的存储过程start_logmnr启动分析;
.png
这样就可以通过下面的查询来获取日志文件的内容了。
4、查询与dbms_logmnr相关的几个视图来获取日志文件内容;
.png
这样就可以找出要恢复所需的语句。注意:v$logmnr_contents只对执行dbms_logmnr.start_logmnr的会话有效,如果通过其他会话或者使用dbms_logmnr.end_logmnr终止了分析,都将不能访问v$logmnr_contents的数据。如果要使其他会话也能获取到这些数据,可以通过另外建表来实现,如:
create table undo_sql as select * from v$logmnr_contents。
再对undo_sql进行授权,其他用户就可以访问v$logmnr_contents的数据了。
5、使用dbms_logmnr里的存储过程end_logmnr结束分析。
使用完成以后用下面的命令来结束分析活动:exec dbms_logmnr.end_logmnr;
这样就释放了分配给logminer的资源(内存和数据结构)。
从上面的过程可知,如果是更新的数据量比较大,而日志文件比较小,就可能会导致日志文件的切换。如果没有及时去挖掘日志文件(没有运行在归档模式),那么可能会由于日志文件的循环使用而导致数据不可恢复。如果运行在归档模式,也可能由于需要分析的日志文件比较多而时间较长。
四、利用flashback新特性恢复数据
Oracle9i 开始提供了闪回查询(Flashback Query)功能,对于误删除或者误更新并且已经commit了的情况提供了简便快捷的恢复方法;而在Oracle 提供闪回查询之前,碰到这种情况只能通过备份来进行基于时间点的恢复或者使用logmnr挖掘日志来恢复,无疑这比闪回查询要麻烦而且费时。
使用这个Flashback Query特性的前提条件:
1. 数据库必须处于Automatic Undo Management 状态。
.png
2. 最大可以闪回查询的时间段由UNDO_RETENTION 初始化参数(单位为秒)指定
.png
可以通过ALTER SYSTEM SET UNDO_RETENTION = ;来动态修改参数值。
▲如何使用Flashback Query来恢复数据呢?
1. 通过SQL
.png
使用SELECT 语句的AS OF 来进行闪回查询,语法如下:
使用AS OF 关键字来对表,视图或者物化视图进行Flashback Query,如果指定了SCN,那么expr 部分必须是一个数字,如果指定了TIMESTAMP,那么expr 必须是一个timestamp类型的值。查询结果将返回在指定的SCN 或者时间点上的数据。
下面我们使用scott 方案来作一个实验。
.png
如果想在update 的子查询部分使用AS OF,那么该查询只能返回一条记录,否则将会报错。
可以通过添加一个临时表作为中转,然后再作更新,如下:
.png
2.通过DBMS_FLASHBACK包来恢复
DBMS_FLASHBACK 包提供了以下几个函数:
ENABLE_AT_TIME:设置当前SESSION 的闪回查询时间
ENABLE_AT_SYSTEM_CHANGE_NUMBER:设置当前SESSION 的闪回查询SCN
GET_SYSTEM_CHANGE_NUMBER:取得当前数据库的SCN
DISABLE:关闭当前SESSION 的闪回查询
当将一个SESSION 设置为闪回查询模式之后,后续的查询都会基于那个时间点或者SCN 的数据库状态,如果SESSION 结束,那么即使没有明确指定DISABLE,闪回查询也会自动失效。
当SESSION 运行在闪回查询状态时,不允许进行任何DML 和DDL 操作。如果要用DML操作来进行数据恢复就必须使用PL/SQL 游标。
▲示例:
.png
通过上面的例子可以看出,只要这个修改的时间不早于sysdate- (UNDO_RETENTION指定的秒数),就可通过这种方式来恢复数据。
.png
对于问题中的批量数据,可以写个过程来完成获取到更改前的数据:
然后再用这个临时表里的数据来更新TFUNDASSET就可以了。
五、总结
比较以上几种恢复数据的方法的使用过程,我们可以看出:
● exp/imp只适合于数据变化不大的表的数据丢失的情况,即使用这种方法处理后也需要从业务办理资料中修正数据,否则导致数据丢失;
● 采用基于时间点的不完全恢复可以恢复丢失的数据,但是需要关关闭数据库,减少系统可用时间,而且也会丢失恢复时间点以后的数据;
● 使用LogMiner可以较好的恢复数据,但是要求数据库尽可能运行在归档模式,否则也可能导致数据丢失。好处是不用关闭系统,能够从日志文件中得到所有的数据。
● 使用Flashback最方便和简洁,可以直接得到修改前的数据,但是需要依赖系统设置,并且需要占用大量的回滚表空间。
因此选择什么样的方法来恢复数据,取决于你的系统环境和具体情况,不能生搬硬套。采用正确的方法才能最大程度的减少数据的丢失。
当然,最好是不需要用到这些恢复的办法。前提是,你必须做好以下的工作:
1、 为不同环境创建不同的数据库用户、不同密码(如果不能用户不同,一定要密码不同);
2、 将owner和应用用户分开,并做适度授权;
3、 在做DML前,先用同样的条件做查询,看根据结果集是否符合预期。
⑵ sql server中怎样创建保存数据的存储过程
在SQL Server中,可以使用两种方法创建存储过程 :
利用SQL Server 管理平台创建存储过程。
使用Transact-SQL语句中的CREATE PROCEDURE命令创建存储过程。
创建存储过程时,需要确定存储过程的几个组成部分:
①所有的输入参数以及传给调用者的输出参数。
②被执行的针对数据库的操作语句,包括调用其它存储过程的语句。
③返回给调用者的状态值,以指明调用是成功还是失败。
④捕获和处理潜在的错误所需的任何错误处理语句
定义存储过程的语法
CREATE PROC[EDURE] 存储过程名
@参数1 数据类型 = 默认值 OUTPUT,
…… ,
@参数n 数据类型 = 默认值 OUTPUT
AS
SQL语句
GO
⑶ SQL SERVER 如何应用存储过程呢操作方法有什么呢
SQL SERVER 如何应用存储过程呢?
首先最好在SQL SERVER的管理工具中通过create procere写一条语句来创建存储过程,创建语句后,点击工具栏中的执行命令,消息栏中显示命令已成功完成的消息,证明存储过程已创建。然后就可以在存储过程子文件夹下看到自己创建的存储过程了,执行存储过程,可以使用exec命令,后跟存储过程的名称,另外,还可以在创建存储过程的时候传入参数,如下图,需要使用@符号传入参数,如果你的存储过程加了参数,那么如果你调用的时候没有传入参数,SQL SERVER会提示错误。

3、存储过程减少网络流量对于数据库对象的相同操作,如果将此次操作所涉及的T-SQL语句组织成一个存储过程,在客户端调用该存储过程时,只在网络上传递调用语句,否则会是多条 SQL 语句。从而减轻了网络流量,降低了网络负载存储过程可以用作安全机制,系统管理员可以对要执行的存储过程的权限进行限制,从而限制对某些数据的访问,避免未经授权的用户访问数据,保证数据安全。
⑷ Oracle 存储过程建立问题
alter index alarminfo1 rebuild;
这个得用动态语句执行,改成这样:
create or replace procere rebuild_index Is
--说 明:重建告警索引,压缩表空间
begin
execute immediate 'alter index alarminfo1 rebuild';
commit;
end rebuild_index;
⑸ sqlserver 2000 怎么新建存储过程
sqlserver 2000 新建存储过程的方法:
一、这里以“学生库”为例,为“学生库”创建一个存储过程。
①首先启动企业管理器,打开数据库,将焦点置于“存储过程”项上。然后,单击鼠标右键。
②在快速菜单中,选择“新建存储过程”,弹出“存储过程编辑窗口”。
二、在创建存储过程中注意下列几点:
1、不能将 CREATE PROCEDURE 语句与其它 SQL 语句组合到单个批处理中。
2、创建存储过程的权限默认属于数据库所有者,所有者可将此权限授予其他用户。
3、存储过程是数据库对象,其名称必须遵守标识符规则。
4、只能在当前数据库中创建存储过程。
⑹ SQL Server 优化存储过程的方法有哪些
优化存储过程有很多种方法,下面介绍最常用的7种。
1.使用SET NOCOUNT ON选项
我们使用SELECT语句时,除了返回对应的结果集外,还会返回相应的影响行数。使用SET NOCOUNT ON后,除了数据集就不会返回额外的信息了,减小网络流量。
2.使用确定的Schema
在使用表,存储过程,函数等等时,最好加上确定的Schema。这样可以使SQL Server直接找到对应目标,避免去计划缓存中搜索。而且搜索会导致编译锁定,最终影响性能。比如select * from dbo.TestTable比select * from TestTable要好。from TestTable会在当前Schema下搜索,如果没有,再去dbo下面搜索,影响性能。而且如果你的表是csdn.TestTable的话,那么select * from TestTable会直接报找不到表的错误。所以写上具体的Schema也是一个好习惯。
3.自定义存储过程不要以sp_开头
因为以sp_开头的存储过程默认为系统存储过程,所以首先会去master库中找,然后在当前数据库找。建议使用USP_或者其他标识开头。
4.使用sp_executesql替代exec
原因在Inside Microsoft SQL Server 2005 T-SQL Programming书中的第四章Dynamic SQL里面有具体描述。这里只是简单说明一下:sp_executesql可以使用参数化,从而可以重用执行计划。exec就是纯拼SQL语句。
5.少使用游标
可以参考Inside Microsoft SQL Server 2005 T-SQL Programming书中的第三章Cursors里面有具体描述。总体来说,SQL是个集合语言,对于集合运算具有较高的性能,而Cursors是过程运算。比如对一个100万行的数据进行查询,游标需要读表100万次,而不使用游标只需要少量几次读取。
6.事务越短越好
SQL Server支持并发操作。如果事务过多过长,或是隔离级别过高,都会造成并发操作的阻塞,死锁。此时现象是查询极慢,同时cup占用率极低。
7.使用try-catch来处理错误异常
SQL Server 2005及以上版本提供对try-catch的支持,语法为:
begin try
----your code
end try
begin catch
--error dispose
end catch
一般情况可以将try-catch同事务结合在一起使用。
begin try
begin tran
--select
--update
--delete
--…………
commit
end try
begin catch
--if error
rollback
end catch
====================== 分割线 =======================
‘自己的一些调优经验’
1. 少使用游标是个很好的建议,为此,我自己也遇到过一些事故,是游标所造成的,由于,游标是逐行逐行操作的,当记录较多时,经常会遇到超时的情况。
2. 多表join做查询时,查询的字段尽量不要使用case when then else end的语法,或者使用用户函数,例如:
select (case when fType=1 then '是' else '否' end) as fTypeName, dbo.F_GetFullName(fID) as fFullName from Table1 inner join Table2……
当两个表的数据量非常大时,你可以在查询分析器中明显感觉到:直接查询fType和fID与查询上面两个字段的速度,很可能使用了一个case when then就导致超时。
针对这种情况,可以分两种做法:
第一,把一些简单的转换可以放在程序中完成。
第二,如果需要通过ID查询全名或者全称,类似的,可以创建好视图,直接查视图,或者,先把所有的fFullName查出来放到临时表中,直接join临时表(如果这个数据不是很多的话),获得fFullName。
3. 少使用一些嵌套的查询,用临时表缓存中间数据,例如:
select * from Table1
inner join (
select count(1) as count, Table2.ID2 from Table2 inner join Table3 on ID2=ID3 group by Table2.ID2
) as t1 on t1.ID1 = Table1.ID1
我曾经遇到这样情况,上面的语句是那种情况的简化版本,把其他不影响结果的表格都去掉了,发现一个奇怪的现象:嵌套查询的结果集并不大,大约就200多行,Table1有6w条记录,结果,这个查询语句超时,查询分析器中执行2分钟也得不到结果。
后来,这样一改,就Ok了,3秒出结果:
select count(1) as count, Table2.ID2 into #temp from Table2 inner join Table3 on ID2=ID3 group by Table2.ID2
select * from Table1
inner join #temp as t1 on t1.ID1 = Table1.ID1
这样一改,效率提升了几十倍,猜想:可能是嵌套的查询是动态的,每一行的join可能都需要先执行嵌套的查询,从而导致效率极差。
所以,如果查询足够复杂,join多个表,需要连接多个通过group by求和、求平均数等运算计算出来的中间数据,那么,不妨多使用临时表缓存中间数据。
4. 还有一些是必须遵守的一些默认规则,比如:
先过滤后连接。
查询的字段最要不要用“*”,指定需要用的字段,减少网络流量。
‘总结’
对于性能的追求是没有极限的,做到你所能做到的,这是一个很好的习惯。
有些业务逻辑放在存储过程中处理比较方便,而有些业务逻辑交给程序来处理,同样会提升系统整体的效率,看实际情况而定。
总之,尽可能减少这些容易引发性能问题的隐患,系统就会跑得更稳定更有效率,一切从小细节做起。
⑺ 用sqlserver存储过程重建索引,该怎么解决
如果语句是你想要的,就把它放到存储过程里面
Use [数据库名称]
Go
DECLARE @DBCCString NVARCHAR(1000)
DECLARE @TableName VARCHAR(100)
DECLARE Cur_Index CURSOR
FOR
SELECT Name AS TblName
FROM sysobjects
WHERE xType='U'
ORDER BY TblName
FOR READ ONLY
OPEN Cur_Index
FETCH NEXT FROM Cur_Index
INTO @TableName
WHILE @@FETCH_STATUS=0
BEGIN
SET @DBCCString = 'DBCC DBREINDEX(@TblName,'''')WITH NO_INFOMSGS'
EXEC SP_EXECUTESQL @DBCCString,N'@TblName VARCHAR(100)', @TableName
PRINT '重建表' + @TableName +'的索引........OK!'
FETCH NEXT FROM Cur_Index INTO @TableName
END
CLOSE Cur_Index
DEALLOCATE Cur_Index
PRINT '操作完成!'
go
⑻ 如何修改存储过程 (SQL Server Management Studio)
两种方法:1图形化界面操作,右键你要修改的存储过程,点击修改
2、SQL语句修改,alert
proc
你要修改的存储过程
⑼ SQL 存储过程建立和使用方法
存储过程没有想象中的那么复杂,也就是普通的SQL语句,带变量的SQL,以及带参数的存储过程。LZ的复制粘贴,初学者看得头大,你看我的就可以了。
如带变量的存储过程:
数据表TABLE有YEARMONTH字段,里面存储的是201001,201002这样的年月
=========================
CREATE
PROC
dbo.PROC_TESTPROC
AS
DECLARE
@DATE
DATETIME,@YEARMONTH
VARCHAR(6)
SET
@DATE=GETDATE()
SET
@YEARMONTH=CONVERT(VARCHAR(4),YEAR(@DATE))+RIGHT('0'+CONVERT(VARCHAR(2),MONTH(@DATE)),2)
SELECT
*
FROM
TABLE
WHERE
YEARMONTH=@YEARMONTH
GO
===========================
执行也非常简单
EXEC
dbo.PROC_TESTPROC
如果有参数,后面跟参数,注意数值及字符型变量
dbo.PROC_TESTPROC
001,'001'
