将数据库内的各对象以二进制方式下载成dmp文件,方便数据迁移。
buffer:下载数据缓冲区,以字节为单位,缺省依赖操作系统
consistent:下载期间所涉及的数据保持read only,缺省为n
direct:使用直通方式 ,缺省为n
feeback:显示处理记录条数,缺省为0,即不显示
file:输出文件,缺省为expdat.dmp
filesize:输出文件大小,缺省为操作系统最大值
indexes:是否下载索引,缺省为n,这是指索引的定义而非数据,exp不下载索引数据
log:log文件,缺省为无,在标准输出显示
owner:指明下载的用户名
query:选择记录的一个子集
rows:是否下载表记录
tables:输出的表名列表
导出整个实例
exp dbuser/oracle file=oradb.dmp log=oradb.log full=y consistent=y direct=y
user应具有dba权限
导出某个用户所有对象
exp dbuser/oracle file=dbuser.dmp log=dbuser.log owner=dbuser buffer=4096000 feedback=10000
导出一张或几张表
exp dbuser/oracle file=dbuser.dmp log=dbuser.log tables=table1,table2 buffer=4096000 feedback=10000
导出某张表的部分数据
exp dbuser/oracle file=dbuser.dmp log=dbuser.log tables=table1 buffer=4096000 feedback=10000 query=\”where col1=\’…\’ and col2 \<…\”
不可用于嵌套表
以多个固定大小文件方式导出某张表
exp dbuser/oracle file=1.dmp,2.dmp,3.dmp,… filesize=1000m tables=emp buffer=4096000 feedback=10000
这种做法通常用在:表数据量较大,单个dump文件可能会超出文件系统的限制
直通路径方式
direct=y,取代buffer选项,query选项不可用
有利于提高下载速度
consistent选项
自export启动后,consistent=y冻结来自其它会话的对export操作的数据对象的更新,这样可以保证dump结果的一致性。但这个过程不能太长,以免回滚段和联机日志消耗完
imp
将exp下载的dmp文件上载到数据库内。
buffer:上载数据缓冲区,以字节为单位,缺省依赖操作系统
commit:上载数据缓冲区中的记录上载后是否执行提交
feeback:显示处理记录条数,缺省为0,即不显示
file:输入文件,缺省为expdat.dmp
filesize:输入文件大小,缺省为操作系统最大值
fromuser:指明来源用户方
ignore:是否忽略对象创建错误,缺省为n,在上载前对象已被建立往往是一个正常现象,所以此选项建议设为y
indexes:是否上载索引,缺省为n,这是指索引的定义而非数据,如果上载时索引已建立,此选项即使为n也无效,imp自动更新索引数据
log:log文件,缺省为无,在标准输出显示
rows:是否上载表记录
tables:输入的表名列表
touser:指明目的用户方
导入整个实例
imp dbuser/oracle file=oradb.dmp log=oradb.log full=y buffer=4096000 commit=y ignore=y feedback=10000
导入某个用户所有对象
imp dbuser/oracle file=dbuser.dmp log=dbuser.log fromuser=dbuser touser=dbuser2 buffer=2048000 commit=y ignore=y feedback=10000
导入一张或几张表
imp dbuser2/oracle file=user.dmp log=user.log tables=table1,table2 fromuser=dbuser touser=dbuser2 buffer=2048000 commit=y ignore=y feedback=10000
以多个固定大小文件方式导入某张表
imp dbuser/oracle file=\(1.dmp,2.dmp,3.dmp,…\) filesize=1000m tables=emp fromuser=dbuser touser=dbuser2 buffer=4096000 commit=y ignore=y feedback=10000
目的:创建一个实体化视图站点,定时刷新,获取主站点中指定表的变化,这个实体化站点可以作为查询服务器使用
步骤:
1。主站点上创建实体化视图日志表
CREATE MATERIALIZED VIEW LOG ON kamus.account2004;
2。实体化视图站点上创建公用数据库链接
conn system/password
CREATE PUBLIC DATABASE LINK orcl using 'ORCL';
3。实体化视图站点上创建刷新组,本例中3分钟刷新一次
conn system/password
BEGIN
DBMS_REFRESH.MAKE (
name => 'kamus.test_repg',
list => '',
next_date => SYSDATE,
interval => 'SYSDATE + 3/(24*60)',
implicit_destroy => FALSE,
rollback_seg => '',
push_deferred_rpc => TRUE,
refresh_after_errors => FALSE);
END;
/
COMMIT;
注意:此处必须commit,否则创建的刷新组并没有真正生效。
4。实体化视图站点上创建用户私有数据库链接
conn kamus/password
CREATE DATABASE LINK orcl CONNECT TO kamus IDENTIFIED BY password;
5。实体化视图站点上创建实体化视图
conn kamus/password
CREATE MATERIALIZED VIEW KAMUS.ACCOUNT2004 REFRESH FAST WITH PRIMARY KEY AS SELECT * FROM KAMUS.ACCOUNT2004@orcl;
6。实体化视图站点上将创建的视图加入刷新组
conn kamus/password
exec DBMS_REFRESH.ADD(name => 'kamus.TEST_REPG', list => 'kamus.ACCOUNT2004', lax => TRUE);
7。测试,在主站点中更新ACCOUNT2004表,过3分钟检查实体化试图站点中的视图,发现更新已经复制成功。
以上为建立只读实体化视图站点的最简单方法:
不需要创建其它的任何用户,比如复制环境中需要的传播者,刷新者,接收者等等
不需要创建任何复制组
不需要生成任何复制对象,不需要生成任何对象的复制支持
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
PL/SQL Release 8.1.7.0.0 - Production
CORE 8.1.7.0.0 Production
TNS for 32-bit Windows: Version 8.1.7.0.0 - Production
NLSRTL Version 3.4.1.0.0 - Production
但是在特定的操作系统下,可能提供了一定的手段,使得我们可以使用超过1.7G的内存,达到2G以上甚至更多。
对于oracle 来说,存在着32bit 与64bit 的问题。这个问题影响到的主要是SGA 的大小。在32bit 的数据库下,通常oracle 只能使用不超过1.7G 的内存,即使我们拥有12G 的内存,但是我们却只能使用1.7G,这是一个莫大的遗憾。假如我们安装64bit 的数据库,我们就可以使用很大的内存,我们几乎不可能达到上限。但是64bit 的数据库必须安装在64bit 的操作系统上,可惜目前windows 上只能安装32bit 的数据库,我们通过下面的方式可以查看数据库是32bit 还是64bit:
SQL> select * from v$version; BANNER
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production PL/SQL Release 8.1.7.0.0 - Production CORE 8.1.7.0.0 Production TNS for 32-bit Windows: Version 8.1.7.0.0 - Production NLSRTL Version 3.4.1.0.0 - Production
但是在特定的操作系统下,可能提供了一定的手段,使得我们可以使用超过1.7G 的内存,达到2G 以上甚至更多。在这里我们针对不同的平台下的具体实现方式做一个总结。
写这个也是因为近来这种重复性的问题发生的太多所导致的
首先不要迷信STS,SG,OCP,EXPERT 等给出的任何建议、内存百分比的说法
基本掌握的原则是, data buffer 通常可以尽可能的大,shared_pool_size 要适度,log_buffer 通常大到几百K到1M就差不多了
设置之前,首先要明确2个问题
1: 除去OS和一些其他开销,能给ORACLE使用的内存有多大
2:oracle是64bit or 32 bit,32bit 通常 SGA有 1.7G 的限制(某些OS的处理或者WINDOWS上有特定设定可以支持到2G以上甚至达到3.7G,本人无这方面经验)
下面是我的windows2000下的oracle :
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
PL/SQL Release 8.1.7.0.0 - Production
CORE 8.1.7.0.0 Production
TNS for 32-bit Windows: Version 8.1.7.0.0 - Production
NLSRTL Version 3.4.1.0.0 - Production
SQL>
windows上存在32bit的限制,如AIX、HP UNIX 等有明确的64BIT OS and ORACLE的版本,32bit oracle可以装在64bit os 上,64 bit oracle不能装在32 bit OS上
不管oracle是32 bit ORACLE还是 64 bit 的,假定应用存在没有很好的使用bind var 的情况,也不能设置 shared_pool_size 过大,通常应该控制在200M--300M,如果是 ORACLE ERP 一类的使用了很多存储过程函数、包 ,或者很大的系统,可以考虑增大shared_pool_size ,但是如果超过500M可能是危险的,达到1G可能会造成CPU的严重负担,系统甚至瘫痪。所以shared_pool_size 如果超过300M还命中率不高,那么应该从应用上找原因而不是一味的增加内存,shared_pool_size 过大主要增加了管理负担和latch 的开销。
log_buffer : 128K ---- 1M 之间通常问题不大,不应该太大
large_pool_size :如果不设置MTS,通常在 RMAN 、OPQ 会使用到,但是在10M --- 50M 应该差不多了。假如设置 MTS,则由于 UGA 放到large_pool_size 的缘故,这个时候依据 session最大数量和 sort_ares_size 等参数设置,必须增大large_pool_size 的设置,可以考虑为 session * (sort_area_size + 2M)。这里要提醒一点,不是必须使用MTS,我们都不主张使用MTS,尤其同时在线用户数小于500的情况下。
java_pool_size : 若不使用java,给30M通常就够了
data buffer ,在做了前面的设置后,凡可以提供给oracle的内存,都应该给data buffer = (db_block_size * db_block_buffers)
在9i 中可以是 db_cache_size
还有2个重要参数我们需要注意
sort_area_size and hash_area_size
这两个参数在非MTS下都是属于PGA ,不属于SGA,是为每个session单独分配的,在我们的服务器上除了OS + SGA,一定要考虑这两部分
(****) : OS 使用内存+ SGA + session*(sort_area_size + hash_area_size + 2M) < 总物理RAM 为好
这样归结过来,假定oracle是 32 bit ,服务器RAM大于2G ,注意你的PGA的情况,,则建议
shared_pool_size + data buffer +large_pool_size + java_pool_size < 1.6G
再具体化,注意满足上面(****) 的原则的基础上可以参考如下设置
如果512M RAM
建议 shared_pool_size = 50M, data buffer = 200M
如果1G RAM
shared_pool_size = 100M , data buffer = 500M
如果2G
shared_pool_size = 150M ,data buffer = 1.2G
物理内存再大已经跟参数没有关系了
假定64 bit ORACLE
内存4G
shared_pool_size = 200M , data buffer = 2.5G
内存8G
shared_pool_size = 300M , data buffer = 5G
内存 12G
shared_pool_size = 300M-----800M , data buffer = 8G
以上仅为参考值,不同系统可能差异比较大,需要根据具体情况调整。建议在设置参数的同时,init中使用 lock_sga ,在不同的平台上可能有不同的方式,使得SGA锁定在物理内存中而不被放入 SWAP 中,这样对效率有好处
关于内存的设置,要再进行细致的调整,起的作用不大,但可根据statspack信息和v$system_event,v$sysstat,v$sesstat,v$latch 等view信息来考虑微调
Oracle是一个磁盘I/O强烈的应用,要确保你恰当地配置磁盘和文件系统:
在磁盘上建立数据文件前首先运行磁盘碎片整理程序
为了安全地整理磁盘碎片,需关闭打开数据文件的实例,并且停止服务。如果你有足够的连续磁盘空间建立数据文件,那么你就很容易避免数据文件产生碎片。
不要使用磁盘压缩
Oracle数据文件不支持磁盘压缩。
不要使用磁盘加密
加密象磁盘压缩一样增加了一个处理层降低磁盘读写速度。如果你担心自己的数据可能泄密,就使用dbms_obfuscation包和label security选择性地加密数据的敏感部分。
不要使用超过70%的磁盘空间
剩余的磁盘空间存放系统临时数据和作为磁盘碎片整理程序存放中间数据。
使用RAID
选择硬件RAID超过软件RAID;
带有硬件RAID控制器;
日志文件不要放在RAID 5卷上,因为RAID 5读性能高而写性能差。
把日志文件和归档日志放在与控制文件和数据文件分离的磁盘控制系统。
分离页面交换文件到多个磁盘物理卷
跨越至少两个磁盘建立两个页面文件。你可以建立四个页面文件并在性能上受益,确保所有页面文件的大小之和至少是物理内存的两倍。
二、优化CPU使用和配置
取消屏幕保护
屏幕保护吸取大量的CPU资源而且提供的是对数据库服务器毫无意义的用处,特别要禁止3GL屏幕保护,如果你必须使用屏幕保护就用“空屏幕”减少CPU使用。
把系统配置为应用服务器
运行控制面板的“系统”,在高级选项卡中设置“性能选项”到“后台程序”,这提供优先权给应用程序,象类似Oracle的服务,反对用户在图形用户界面启动一个笨拙的程序。
监视系统中消耗中断的硬件
消耗CPU中断和时间的硬件应该避免使用。通常这样的硬件是便宜的因为它把工作载入CPU,而CPU要处理外围的高级性能的硬件,通常需要注意:
1、支持总线控制的网卡
2、支持DMA而不支持PIO的磁盘控制器
使用性能监视器跟踪处理器对象的%Interrupt Time 计数器数值,和这个计数器的基线和标准,然后监视问题。
3、有利避免中断的方式是使用硬件RAID控制器代替Windows 2000支持的软件RAID。
保持最小的安全审计记录
在专用服务器上运行Oracle
Oracle是内存消耗大户,不要在执行下列功能的系统上运行Oracle数据库:
1、主域或备份域控制器(Windows 2000下都称域控制器)
2、文件服务器
3、打印服务器
4、远程访问服务器
5、路由器、代理或防火墙
不要使用花哨的壁纸(如果使用,要尽量减小壁纸文件大小)
禁止非必须的服务
最好禁止系统里非必须的服务,如果时而需要某些服务功能,可将启动类型设置为“手动”,要做到这一点首先同网络管理员验证实际的服务需求:
1、如果你的系统不需要打印机,通常停止这个服务并设置为手动;
2、停止License Logging Service服务除非你对它有特殊要求;
3、不应该使用DHCP服务,并禁止它;
4、不要自动启动你不需要的程序;
检查菜单“开始/程序/启动”里的内容,删除不需要的程序。
三、优化网络配置
网络配置是性能调整的一项很重要的内容,而且很容易隐藏性能瓶颈。
配置网卡使用最快速度和有效模式
这针对自动检测,大多数缺省安装是NIC,如果这是可选的就尽量调整为“全双工”和最大化线速度。
删除不需要的网络协议
只保留TCP/IP协议。
优化网络协议绑定顺序
在每个网卡上设置主协议,典型地是TCP/IP,到协议列表的顶端。
为Oracle禁止或优化文件共享
理想地应该禁止文件共享功能来最小化安全泄露和网络交通,但如果你需要使用文件和打印共享,那么就配置系统中每个网卡的“连接属性”,设置“最大化网络应用程序数据吞吐量”
四、内存调优
内存优化是Windows平台的关键设置,首先了解一下Windows 2000平台的Oracle结构:
基于线程的结构
Windows2000是基于线程的结构,相反,Unix操作系统是基于进程的结构。这意味着Windows中更多的应用,包括Oracle在内,是以带有多个线程的单个进程的形式执行,这种基于线程的结构的确给Window2000带来优势——更容易共享内存。内存空间为每个进程分配,进程间共享内存很笨拙,要使用附加编码,线程是进程的子集,使用比进程少得多的内存。特定进程的所有线程共享同样的进程内存空间,同一进程的线程间共享内存比不同进程共享内存要快,这给基于线程的结构很大优势,更有效。
在服务器上运行的每个应用程序都有一个,而且只有一个进程。进程是应用程序的载体,是用来容纳执行应用程序实际工作的线程的。从用户角度看,进程是不用任何专门工具就可以看到的组件。进程对其他应用程序组件的作用就像容器一样。它持有虚拟的存储空间、数据、系统资源和应用程序设置。虽然线程可以分配、重新分配和释放内存,但是进程接受初始的内存分配,并将它分配到请求内存的所有线程。线程是包含在进程内共享所有进程资源的单个执行路径。它还包含堆栈(存储在内存中的变量和其他数据)、CPU寄存器的状态信息(所以,线程可以恢复它的环境)、和在系统调度程序的执行列表中的一个登录项。每个线程规定了完成任务应用程序需要作的某种工作。
使用Task Manager的主要问题是看不到任何线程。Task Manager被设计成从进程层将应用程序作为整体看待。当然还可以使用性能监视器来监视Windows下的Oracle内存使用。
从“开始/程序/管理工具”选择“性能”启动“系统监视器”。注意,“性能”包括两个MMC插件:“系统监视器”和“性能日志和变更”。这时,需要一些被监视的计数器(计数器是一些性能指示器,用于对 Windows 2000的特殊对象进行统计,例如统计特定线程所要求的处理器时间)。单击“添加”按钮(在图中看起来象一个加号),将看到“添加计数器”对话框。首先需要选择想监视的“性能”对象。在包含“进程”对象和“线程”对象的“性能”下拉列表中选择。
进程观察器(Process Viewer)是比较容易检查线程和进程的方法之一。可以在 Windows 2000 Support Tools 或Windows 2000 Resource Kit内找到一些工具。Windows 2000 Support Tools是Windows 2000的一部分,但是并不自动安装。支持安装的Windows Installer文件在%CDROM%\SUPPORT\TOOLS\目录下。只要在2000RKST.MSJ上右击,并从context菜单上选择安装即可。
内存
基于线程的结构的确有一些内存限制,因为单个进程由线程组成,而进程的地址空间是受限的,因此很少有空间是机动的。因为Windows 2000仍然是32为操作系统,单个进程地址空间被限制在4GB内,其中一半被操作系统保留,这2GB被OS保留的系统内存也被视为系统地址空间,他包括 OS内核编码、硬件抽象层编码(HAL)和需要管理进程和OS交互的不同的其它结构,这2GB的系统地址空间是禁止应用程序进程访问的。
因此,Windows 2000标准服务器单个应用程序进程可使用内存空间共2GB。在Windows 2000高级服务器启动文件boot.ini中有/3GB开关,改变这个比例到3GB,这项技术被称作4GB调优(4-gigabyte tuning,或4GT),我们将针对这个问题展开详细讨论。
保留的内存是分配给线程的内存并且留作将来使用,但没有实际使用的内存。因为没有实际使用,因此它对其它进程仍然有效。但是,因为它已经被分配,它仍然由对拥有线程的进程的总的内存限制产生,因此,保留内存的计算针对2GB或3GB的限制,并且进程保留的和使用的内存的总和不能超过这个限制。
除了系统中安装的物理内存之外,Windows 2000还使用虚拟内存。这实际上是驻留在硬盘上的内存。但是Windows 2000使得它对应用程序来说,就像是安装在机器上内存一样。当某个应用程序块要求访问那个内存时,Windows 2000就把另外的内存块复制到磁盘上,而把所要求的内存放到物理内存中,这些内存块的大小是4KB。也就是说,每次应用程序提出对内存的要求时,内存就被分配在4KB的页面内。在磁盘上模拟内存的文件叫做页面调度文件。Virtual Memory Manager(VMM虚拟内存管理器)是操作系统管理机器上的虚拟内存组件。所有的内存访问都通过VMM。这意味着每当操作系统需要进行内存调页时,就要提出VMM请求。
内存调优方法:
(一)使用超过4GB的内存
另外,有办法允许为单个进程或应用分配超过32位地址空间的内存,为实现这一点,Windows 2000使用物理地址扩展(physical address extensions ,或PAE),PAE本质上把地址空间从32位增加到36位,但是必须有Pentium Pro或更新的处理器才能享受这个优势。在Windows NT 4.0下,Intel提供PSE36驱动程序享受全部36位地址空间的优势,但是在Windows 2000 Advanced Server中36位地址空间的支持已经建立在操作系统中,然而,应用程序必须使用地址窗口扩展(Address Windowing Extensions ,或AWE)API写成,Oracle9i 发行号1(Release 1)不支持AWE,所有的Oracle 8i发行号(releases 8.1.5–8.1.7)都支持AWE。Oracle在9i发行号2(Release 2)中实现了对AWE的支持。
(二)AWE和Windows 2000
AWE允许你使用系统中任何附加的超过4GB的内存,为了体现这个优势,你必须有超过 4GB的内存,必须有Pentium Pro或更新的处理器,必须运行Windows 2000高级服务器或Windows 2000数据中心服务器,不需要特殊的驱动程序,因为Windows 2000已经支持AWE。
为了利用这项优势,必须在启动Windows 2000机器时在boot.ini文件中使用/PAE开关,你必须确保运行Oracle服务的帐户有Lock Pages in Memory权限。给运行Oracle服务的帐户增加Lock Pages in Memory权限后,要重新启动OracleService 服务。
(三)AWE和Oracle
可以确定,Oracle8i所有发行号版本和Oracle9i发行号2只允许你为数据库块缓冲区配置超过4GB限制的内存空间,因此,要为用户连接释放标准进程地址空间的内存(低于3GB界限的内存)、PGA内存和组成SGA的不同内存缓冲池。
在初始化参数文件init.ora中要设置参数USE_INDIRECT_DATA_BUFFERS=TRUE,没有这个参数,Oracle不能寻址到4GB以上的地址空间。接下来要设置决定内存使用总量的缓冲池大小,设定DB_BLOCK_SIZE和DB_BLOCK_BUFFERS两个参数。
在Oracle9i发行号2中,参数DB_BLOCK_BUFFERS被参数DB_CACHE_SIZE所代替,这样就改变了原来指定缓冲区块数到指定缓冲区字节数,同样,也解释了在Oracle9i发行号2的一个数据库中支持多个数据库块大小。无论用哪种办法,如果你设定参数 USE_INDIRECT_BUFFERS=TRUE,你将只能定义和使用单个数据库块大小和块缓冲区(就象在9i以前的发行号中),因此,如果缺省数据库块大小是4k、8k或其它,而设置DB_2k_CACHE_SIZE是不允许的。
接下来需要在注册表中为ORACLE_HOME设置合适的AWE_WINDOW_MEMORY参数值,也就是在 HKEY_LOCAL_MACHINE\ Software\Oracle\HOME0下,这个参数指定字节数,如果没有设置,缺省值是1 GB。这个参数的大小取决于你要设置多少缓冲区大小,并视为来自3GB进程地址空间的常规内存。以缓冲区大小为6 GB为例,设置AWE_WINDOW_MEMORY为缺省值1GB,你希望1GB 视为常规内存,并且剩余5GB缓冲区来自4GB限制以上的地址空间。你希望更多的缓冲池尽可能保留在常规地址空间,因为访问超过4GB以上的缓冲池比访问虚拟地址空间缓冲池要慢(尽管仍然比磁盘I/O操作快)。
(四)解决与AWE相关的内存问题
需要注意的是每个4GB界限以上的块缓冲区需要在常规地址空间保留大约200字节的缓冲区头,因此,在上面的例子中,我们大约有312000个缓冲区头指向扩展地址空间的缓冲区,缓冲区头大约占80MB常规内存空间,如果数据库块很小,那么这个数量会相当高,因此,必须确保这些缓冲区头、AWE_WINDOW_MEMORY、和所有Oracle.exe进程的内存需求,包括编码、SGA其它组件、 PGA内存和每个用户连接栈都适合Oracle.exe进程的常规3GB虚拟地址空间。
确认你有足够的物理内存处理超过AWE_WINDOW_MEMORY之外的DB_BLOCK_BUFFERS,在我们的例子中定义缓冲池大小为 6GB,1GB来自常规地址空间,剩余5GB来自4GB以外的对整个进程有效的系统和进程地址空间,因此,这个例子只能工作在至少有9GB内存的机器上,你还应该为其它进程保留一些空间,只有一个进程可以在某一时刻访问附加的内存。
象前面所说的那样,/PAE开关只用于系统有超过4GB物理内存的时候,但如果系统内存少于4GB时,也可模仿这项功能。在boot.ini文件中设置MAXMEM参数的值,如下面例子,设为2GB,意味着任何2GB以上的内存都将保留为AWE内存。
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Advanced
Server" /fastdetect /PAE /MAXMEM:2048
为一个数据库使用附加的多个进程
真正的应用集群(Real Applications Clusters,RAC)提供有多个实例运行和访问同一数据的能力。通常,这用于有两个或多个节点的项目,一个实例运行在每个节点。无论如何,它支持在 Oracle9i有两个实例运行在一个节点访问同一个数据库。这能克服每个进程的内存限制,又提供某些其它的利益,如应用程序失败检测。
上周一个朋友的数据库发生误删除操作,请我帮忙进行恢复。
由于备份比较充分,所以只需要通过RMAN进行一个基于时间点(这个时间点需要根据故障时间进行判断选取)。
首先启动实例:
[oracle@stat ~]$ export ORACLE_SID=order
[oracle@stat ~]$ rman target /Recovery Manager: Release 10.2.0.2.0 - Production on Thu Sep 14 22:43:50 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database (not started)
RMAN> set DBID=1341966532
executing command: SET DBID
RMAN> startup nomount;
Oracle instance started
Total System Global Area 2483027968 bytes
Fixed Size 1262344 bytes
Variable Size 654314744 bytes
Database Buffers 1811939328 bytes
Redo Buffers 15511552 bytes
恢复数据文件并加载(mount)数据库:
RMAN> restore controlfile from autobackup;Starting restore at 14-SEP-06
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=541 devtype=DISKchannel ORA_DISK_1: looking for autobackup on day: 20060914
channel ORA_DISK_1: autobackup found: c-1341966532-20060914-02
channel ORA_DISK_1: control file restore from autobackup complete
output filename=/oradata/controlfile/o1_mf_28spy45z_.ctl
output filename=/oradata/controlfile/o2_mf_28spy45z_.ctl
Finished restore at 14-SEP-06RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
Restore数据库:
RMAN> restore database;Starting restore at 14-SEP-06
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=541 devtype=DISKchannel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /oradata/datafile/o1_mf_system_28spy7kl_.dbf
restoring datafile 00002 to /oradata/datafile/o1_mf_undotbs1_28spykdh_.dbf
restoring datafile 00003 to /oradata/datafile/o1_mf_sysaux_28spyo9s_.dbf
restoring datafile 00004 to /oradata/datafile/o1_mf_users_28spyvm8_.dbf
restoring datafile 00005 to /oradata/datafile/o1_mf_vascms_2c444bhj_.dbf
restoring datafile 00006 to /oradata/datafile/o1_mf_wapgame_2c44gz55_.dbf
restoring datafile 00007 to /oradata/datafile/o1_mf_vascms_2c4kn0b2_.dbf
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/full_ORDER_20060913_169
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderfullback_ORDER_20060913_169 tag=order
channel ORA_DISK_1: restore complete, elapsed time: 00:03:06
Finished restore at 14-SEP-06
进行基于时间点的恢复:
RMAN> recover database until time '2006-09-14 19:00:00'
2> ;Starting recover at 14-SEP-06
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 09/14/2006 22:49:54
ORA-01861: literal does not match format stringRMAN> exit
Recovery Manager complete.
这个错误是由于时间日期格式设置的问题。
设置正确的时间格式,进行基于时间点的不完全恢复:
[oracle@stat ~]$ export NLS_DATE_FORMAT='yyyy-mm-dd hh24:mi:ss'
[oracle@stat ~]$ rman target /Recovery Manager: Release 10.2.0.2.0 - Production on Thu Sep 14 22:50:22 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: order (DBID=1341966532, not open)
RMAN> recover database until time '2006-09-14 19:00:00'
2> ;Starting recover at 2006-09-14 22:50:26
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=544 devtype=DISKstarting media recovery
archive log thread 1 sequence 303 is already on disk as file
/oradata/archive/1_303_592917188.dbf
archive log thread 1 sequence 304 is already on disk as file
/oradata/archive/1_304_592917188.dbf
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=299
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/arch_order_20060913_171
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderarch_order_20060913_171 tag=order
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
archive log filename=/oradata/archive/1_299_592917188.dbf thread=1 sequence=299
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=300
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=301
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=302
channel ORA_DISK_1: reading from backup piece /data3/ordrbak/arch_order_20060914_173
channel ORA_DISK_1: restored backup piece 1
piece handle=/data3/ordrbak/orderarch_order_20060914_173 tag=TAG20060914T033004
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
archive log filename=/oradata/archive/1_300_592917188.dbf thread=1 sequence=300
archive log filename=/oradata/archive/1_301_592917188.dbf thread=1 sequence=301
archive log filename=/oradata/archive/1_302_592917188.dbf thread=1 sequence=302
archive log filename=/oradata/archive/1_303_592917188.dbf thread=1 sequence=303
archive log filename=/oradata/archive/1_304_592917188.dbf thread=1 sequence=304
media recovery complete, elapsed time: 00:00:57
Finished recover at 2006-09-14 22:51:39
Resetlogs打开数据库:
RMAN> alter database open resetlogs;database opened
RMAN>
此时可以检查数据的正确性,如果无误就可以通过exp导出数据,再imp进生产数据库,完成恢复。
在有了充分的备份的前提下,这样的恢复是非常容易的。
这个故事再次告诉我们:备份重于一切。
-The End-
任何事情都有它的源头,要解决问题,也得从源头开始,影响ORACLE性能的源头非常多,主要包括如下方面:
数据库的硬件配置:CPU、内存、网络条件
1. CPU:在任何机器中CPU的数据处理能力往往是衡量计算机性能的一个标志,并且ORACLE是一个提供并行能力的数据库系统,在CPU方面的要求就更高了,如果运行队列数目超过了CPU处理的数目,性能就会下降,我们要解决的问题就是要适当增加CPU的数量了,当然我们还可以将需要许多资源的进程KILL掉;
2. 内存:衡量机器性能的另外一个指标就是内存的多少了,在ORACLE中内存和我们在建数据库中的交换区进行数据的交换,读数据时,磁盘I/O必须等待物理I/O操作完成,在出现ORACLE的内存瓶颈时,我们第一个要考虑的是增加内存,由于I/O的响应时间是影响ORACLE性能的主要参数,我将在这方面进行详细的讲解
3. 网络条件:NET*SQL负责数据在网络上的来往,大量的SQL会令网络速度变慢。比如10M的网卡和100的网卡就对NET*SQL有非常明显的影响,还有交换机、集线器等等网络设备的性能对网络的影响很明显,建议在任何网络中不要试图用3个集线器来将网段互联。
OS参数的设置
下表给出了OS的参数设置及说明,DBA可以根据实际需要对这些参数进行设置
|
内核参数名 |
说明 |
|
bufpages |
对buffer空间不按静态分配,采用动态分配,使bufpages值随nbuf一起对buffer空间进行动态分配。 |
|
create_fastlinks |
对HFS文件系统允许快速符号链接 |
|
dbc_max_pct |
加大最大动态buffer空间所占物理内存的百分比,以满足应用系统的读写命中率的需要。 |
|
dbc_min_pct |
设置最小动态buffer空间所占物理内存的百分比 |
|
desfree |
提高开始交换操作的最低空闲内存下限,保障系统的稳定性,防止出现不可预见的系统崩溃(Crash)。 |
|
fs_async |
允许进行磁盘异步操作,提高CPU和磁盘的利用率 |
|
lotsfree |
提高系统解除换页操作的空闲内存的上限值,保证应用程序有足够的可用内存空间。 |
|
maxdsiz |
针对系统数据量大的特点,加大最大数据段的大小,保证应用的需要。(32位) |
|
maxdsiz_64bit |
maximum process data segment size for 64_bit |
|
Maxssiz |
加大最大堆栈段的大小。(32_bit) |
|
maxssiz_64bit |
加大最大堆栈段的大小。(64_bit) |
|
Maxtsiz |
提高最大代码段大小,满足应用要求 |
|
maxtsiz_64bit |
原值过大,应调小 |
|
Minfree |
提高停止交换操作的自由内存的上限 |
|
Shmem |
允许进行内存共享,以提高内存的利用率 |
|
Shmmax |
设置最大共享内存段的大小,完全满足目前的需要 |
|
Timeslice |
由于系统的瓶颈主要反映在磁盘I/O上,因此 降低时间片的大小,一方面可避免因磁盘I/O不畅造成CPU的等待,从而提高了CPU的综合利用率。另一方面减少了进程的阻塞量。 |
|
unlockable_mem |
提高了不可锁内存的大小,使可用于换页和交换的内存空间扩大,用以满足系统对内存管理的要求。 |
用户SQL质量
以上讲的都是硬件方面的东西,在条件有限的条件下,我们可以调整应用程序的SQL质量:
1. 不要进行全表扫描(Full Table Scan):全表扫描导致大量的I/O
2. 尽量建好和使用好索引:建索引也是有讲究的,在建索引时,也不是索引越多越好,当一个表的索引达到4个以上时,ORACLE的性能可能还是改善不了,因为OLTP系统每表超过5个索引即会降低性能,而且在一个sql 中, Oracle 从不能使用超过 5个索引;当我们用到GROUP BY和ORDER BY时,ORACLE就会自动对数据进行排序,而ORACLE在INIT.ORA中决定了sort_area_size区的大小,当排序不能在我们给定的排序区完成时,ORACLE就会在磁盘中进行排序,也就是我们讲的临时表空间中排序, 过多的磁盘排序将会令 free buffer waits 的值变高,而这个区间并不只是用于排序的,对于开发人员我提出如下忠告:
1)、select,update,delete 语句中的子查询应当有规律地查找少于20%的表行.如果一个语句查找的行数超过总行数的20%,它将不能通过使用索引获得性能上的提高.
2)、索引可能产生碎片,因为记录从表中删除时,相应也从表的索引中删除.表释放的空间可以再用,而索引释放的空间却不能再用.频繁进行删除操作的被索引的表,应当阶段性地重建索引,以避免在索引中造成空间碎片,影响性能.在许可的条件下,也可以阶段性地truncate表,truncate命令删除表中所有记录,也删除索引碎片.
3)、在使用索引时一定要按索引对应字段的顺序进行引用。
4)、用(+)比用NOT IN更有效率。
降低ORACLE的竞争:
先讲几个ORACLE的几个参数,这几个参数关系到ORACLE的竞争:
1)、freelists 和 freelist 组:他们负责ORACLE的处理表和索引的空间管理;
2)、pctfree 及 pctused:该参数决定了freelists 和 freelist 组的行为,pctfree 和pctused 参数的唯一目的就是为了控制块如何在 freelists 中进出
设置好pctfree 及 pctused对块在freelists的移走和读取很重要。
其他参数的设置
1)、包括SGA区(系统全局区):系统全局区(SGA)是一个分配给Oracle 的包含一个 Oracle 实例的数据库的控制信息内存段。
主要包括数据库高速缓存(the database buffer cache),
重演日志缓存(the redo log buffer),
共享池(the shared pool),
数据字典缓存(the data dictionary cache)以及其它各方面的信息
2)、db_block_buffers(数据高速缓冲区)访问过的数据都放在这一片内存区域,该参数越大,Oracle在内存中找到相同数据的可能性就越大,也即加快了查询速度。
3)、share_pool_size (SQL共享缓冲池):该参数是库高速缓存和数据字典的高速缓存。
4)、Log_buffer (重演日志缓冲区)
5)、sort_area_size(排序区)
<6)、processes (同时连接的进程数)
7)、db_block_size (数据库块大小):Oracle默认块为2KB,太小了,因为如果我们有一个8KB的数据,则2KB块的数据库要读4次盘,才能读完,而8KB块的数据库只要1次就读完了,大大减少了I/O操作。数据库安装完成后,就不能再改变db_block_size的值了,只能重新建立数据库并且建库时,要选择手工安装数据库。
8)、open_links (同时打开的链接数)
9)、dml_locks
10)、open_cursors (打开光标数)
11)、dbwr_io_slaves (后台写进程数)
1.1 测试目的
验证RMAN备份与恢复全过程。记录整个过程的操作细节。
利用RMAN的备份与恢复可完成如下工作:
(1) 数据库备份/恢复;
(2) 同一主机,不同磁盘阵列,相同数据存储路径(模式)的数据迁移;(在恢复过程中改变数据存储路径/模式过程待验证)
(3) 不同主机,相同操作系统、同一数据库版本之间的的数据库迁移。(不同数据库版本之间是否可利用RMAN 备份与恢复进行数据迁移待验证。)
1.2 测试环境说明
• OS:Windows XP
• ORACLE VERSION: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 – Prod
• ORACLE运行模式:归档模式
• ORACLE数据存储:文件系统,存储于D:\oracle\product\10.1.0\oradata\orcl 包含文件如下:
2007-08-15 08:43 2,867,200 CONTROL01.CTL
2007-08-15 08:43 2,867,200 CONTROL02.CTL
2007-08-15 08:43 2,867,200 CONTROL03.CTL
2007-08-15 08:42 10,486,272 REDO03.LOG
2007-08-15 08:42 10,486,272 REDO04.LOG
2007-08-15 08:42 10,486,272 REDO05.LOG
2007-08-15 08:42 10,486,272 REDO06.LOG
2007-08-15 08:53 220,209,152 SYSAUX01.DBF
2007-08-15 08:43 461,381,632 SYSTEM01.DBF
2007-08-15 08:43 26,222,592 UNDOTBS01.DBF
2007-08-15 08:43 5,251,072 USERS01.DBF
2 数据备份过程
2.1 RMAN 数据库全备份
rman nocatalog target /
run
{
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
backup database format 'C:\db_full_%U' include current controlfile;
sql 'alter system archive log current';
#crosscheck archivelog all;
backup format 'c:\arch_full_%U' archivelog all delete input;
release channel c1;
release channel c2;
release channel c3;
}
【注意】
RMAN采用无恢复目录模式
备份数据库过程包含当前控制文件备份
数据库处于归档模式,备份过程包含所有归档日志的备份
数据库必须处于mount或者open状态,才能进行数据库备份
2.2 数据库在数据全备份后继续操作
(1)在RMAN全备份后继续数据库的操作。即在测试表中插入数据。
SQL> conn kfzjd/kfzjd
已连接。
SQL> insert into t values(100);
已创建 1 行。
SQL> insert into t values(200);
已创建 1 行。
SQL> insert into t values(300);
已创建 1 行。
SQL> insert into t values(400);
已创建 1 行。
SQL> commit;
提交完成。
SQL> select * from t;
ID
----------
1
2
3
100
200
300
400
已选择7行。
(2)正常关闭数据库。并删除原数据库所有文件,包括:控制文件、数据文件、日志文件。以模拟更换磁盘阵列或者文件丢失的情况。
SQL> conn / as sysdba
已连接。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host move D:\oracle\product\10.1.0\oradata\orcl D:\oracle\product\10.1.0\oradata\orcl.bak
【注意】
删除文件过程,将以更目录名称的方式,用以模拟新盘阵上的文件存储路径与原系统不同。(^_^)
此时,重新启动数据库过程必然失败。
SQL> conn / as sysdba
已连接。
SQL> startup
ORACLE instance started.
Total System Global Area 171966464 bytes
Fixed Size 787988 bytes
Variable Size 145750508 bytes
Database Buffers 25165824 bytes
Redo Buffers 262144 bytes
ORA-00205: ?????????, ??????, ???????
【注意】此时由于实例存在,但是database全部丢失,则INSTANCE启动成功,但是database启动失败。即可,NOMOUNT状态(只启动INSTANCE)成功;进入MOUNT状态时,由于控制文件丢失,MOUNT 失败。数据库启动过程不能继续。
3 数据库恢复过程
当前情况下,所有的控制文件、数据库文件、联机日志文件均全部丢失。按照数据库恢复/启动过程,应按照先恢复数据库控制文件,再恢复数据文件的步骤进行。
3.1 恢复数据库控制文件
控制文件的恢复,依托于控制文件的备份方式。以下将分别进行说明。
3.1.1 从RMAN备份中恢复控制文件
在本例子中,RMAN备份脚本进行了控制文件的备份。所以,控制文件的恢复过程可以利用RMAN的备份完成。
此时,也存在两种情况。
• RMAN设置了控制文件自动备份。
• RMAN未设置控制文件自动备份,而由RMAN脚本进行控制文件备份。如本例所示。
对于此两种情况,分别说明如下。
3.1.1.1 RMAN未设置控制文件自动备份(本例)
C:\>rman nocatalog target /
恢复管理器: 版本10.1.0.2.0 - Production
Copyright (c) 1995, 2004, Oracle. All rights reserved.
连接到目标数据库: ORCL (DBID=1158376346)
正在使用目标数据库控制文件替代恢复目录
RMAN> show all;
RMAN 配置参数为:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'D:\ORACLE\PRODUCT\10.1.0\DB_1\DATABASE\S
NCFORCL.ORA'; # default
【注意】RMAN 未设置控制文件自动备份。此时如果RMAN 的直接恢复将不成功。如下所示。
RMAN> startup nomount;
Oracle 例程已启动
系统全局区域总计 171966464 字节
Fixed Size 787988 字节
Variable Size 145750508 字节
Database Buffers 25165824 字节
Redo Buffers 262144 字节
RMAN> restore controlfile from autobackup;(由于没有设置自动备份控制文件所以出错)
启动 restore 于 15-8月 -07
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=160 devtype=DISK
恢复区域目标: D:\oracle\product\10.1.0\flash_recovery_area
用于搜索的数据库名 (或锁定名称空间): ORCL
通道 ORA_DISK_1: 在恢复区域中找到自动备份
通道 ORA_DISK_1: 已找到的自动备份: D:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\
ORCL\AUTOBACKUP\2007_08_14\O1_MF_S_630614292_3D31JOHN_.BKP
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/15/2007 09:54:16
ORA-19504: 无法创建文件"D:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\CONTROL01.CTL"
ORA-27040: 文件创建错误, 无法创建文件
OSD-04002: 无法打开文件
O/S-Error: (OS 3) 系统找不到指定的路径。
RMAN> restore controlfile;(语法就错误了)
启动 restore 于 15-8月 -07
使用通道 ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/15/2007 09:54:31
RMAN-06563: controlfile or SPFILE must be restored using FROM AUTOBACKUP
RMAN> restore database;(数据库未到MOUNT状态,不能进行^_^)
启动 restore 于 15-8月 -07
使用通道 ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/15/2007 09:56:57
ORA-01507: 未装载数据库
RMAN> recover database using backup controlfile;(曾经见过ITPUB上有人怎么写,但是无法通过)
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01005: syntax error: found "identifier": expecting one of: "archivelog, aux
iliary, allow, check, delete, from, high, noredo, noparallel, parallel, ;, skip,
tablespace, test, until"
RMAN-01008: the bad identifier was: using
RMAN-01007: at line 1 column 18 file: standard input
RMAN> restore database using backup controlfile; (数据库未到MOUNT状态,不能进行^_^)
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01005: syntax error: found "identifier": expecting one of: "archivelog, cha
nnel, check, controlfile, clone, database, datafile, device, from, force, high,
(, preview, ;, skip, spfile, standby, tablespace, until, validate"
RMAN-01008: the bad identifier was: using
RMAN-01007: at line 1 column 18 file: standard input
RMAN>
由于RMAN未设置控制文件自动备份。则可以利用程序包,从备份集中恢复。如下:
SQL> startup nomount
ORACLE 例程已经启动。
Total System Global Area 171966464 bytes
Fixed Size 787988 bytes
Variabl