首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Oracle数据库备份与恢复方案

    大家好,又见面了,我是你们的朋友全栈君。任何数据库在长期使用过程中,都会存在安全隐患。对于数据库管理员来说不能仅寄希望于计算机操作系统的安全运行,而是要建立一整套的数据库备份与恢复机制。当任何人为的或是自然的灾难一旦出现,而导致数据库崩溃、物理介质损坏等,就可以及时恢复系统中重要的数据,不影响整个单位业务的运作。然而如果没有可靠的备份数据和恢复机制,就会带来系统瘫痪、工作停滞、经济损失等等不堪设想的后果。本文以ORACLE数据库为例,结合医院的业务应用环境,介绍 ORACLE数据库的备份恢复。 首先,应当制定一个严格的工作制度,规范化数据库维护的工作流程。 总结实际工作中的经验,数据库管理员应当按照以下原则进行数据库系统的维护: 要求:每日值班的数据库管理员应当随时监控主数据库服务器、备份数据库服务器的软件、硬件的正常运行,一旦出现故障,应立即向领导汇报并采取相应恢复措施。 一、管理员应当每日察看数据库的冷备份报告,出现问题及时检查备份文件,保障每日数据库服务器的备份正常运行。 二、当主数据库服务器出现数据库错误时,应检查数据库的工作状态。如果工作不正常应及时将最新的备份数据覆盖当前数据库的损坏数据,并重新启动机器,检验数据库系统是否能够自行恢复运行。如果重新启动后数据库系统不能正常运行,则数据库系统文件被破坏,应重新安装ORACLE数据库并启用紧急恢复方案。 三、当主数据库服务器出现硬件故障时,应在1小时内更新备份数据库为最新数据,并启动备份数据库服务器,将备份数据库服务器升级为主数据库服务器。对于损坏的主数据库服务器应重新安装ORACLE数据库,并启用紧急恢复方案。 四、当备份数据库服务器出现数据库错误时,应检查ORACLE数据库的工作状态,如果工作不正常应及时将最新的备份数据覆盖当前数据库的损坏数据,并重新启动机器,检验数据库系统是否能够自行恢复运行。如果重新启动后数据库系统不能正常运行,则数据库系统文件被破坏,应重新安装ORACLE数据库并启用紧急恢复方案。如果ORACLE工作不正常,应重新安装ORACLE数据库并启用紧急恢复方案。 五、当备份数据库服务器出现硬件故障时,应尽快修复。等待硬件正常工作后,首先重新安装ORACLE数据库,并采用紧急恢复方案恢复ORACLE数据库。 六、每周至少三次将备份数据转移到移动磁盘内,以防止出现自然灾害的事故而导致的备份数据丢失。 1.ORACLE数据库系统的安装 首次安装ORACLE7.3数据库。进入安装光盘的NT_x86目录,运行setup.exe,进行安装。选择安装目录:D:ORANT(在本文中以将ORACLE数据库安装到D盘为例,下不累述。) 选择安装模式:oracle7 server product 选中:oracle7 con text option 2.0.4.0.0oracle7 spatail data option 7.3.3.0.0. 选择标准安装模式。配置数据库:在net easy config中添加本地数据库的别名、ip地址。修改注册表的字符集为us7ascii(根据需要)。用internal帐户启动当前数据库,验证当前数据库已正确安装。Shutdown当前数据库。设置数据库为ARCHIVELOG方式: 1)将系统设置成自动归档写满的联机日志文件,修改参数文件D:ORANTDatabaseINITORACL.ORA文件,设置:

    02

    OpenLDAP使用BDB时的一些配置和维护方法

    一、 配置部份 在基本配置完成之后,可以在slapd.conf设置一些提高安全和效率的选项   cachesize 5000   checkpoint 1024 5   cachesize是ldap在内存中缓存的记录条数。这个缓存是openldap自己维护的,与bdb库无关。   为了提高效率bdb在修改数据库时,是先修改内存里面的,然后分批回写到数据库文件里面。Checkpoint操作就是把内存中的数据回写数据库文件的操作。   checkpoint 1024 5表示每写1024kb数据,或者是每隔5分钟,bdb会执行一次checkpoint的操作。   在bdb库中提拱了一个命令db_checkpoint,用来给用户执行checkpoint用。比如,当用户需要删除日志的时候,他需要先执行一下db_checkpoint,来确保数据已经回写到数据库文件中了,这时才能放心地删掉日志。

    02

    GreatSQL5.7数据库DROP表后无法重建

    一、数据库信息: 数据库版本:5.7.21-log 某银行测试数据库,APP业务库内有一个含有大量(几百个)分区表的大表test_app。DROP该分区表的大表后导致无法重建该分区表。 二、问题描述: 客户使用“drop table test_app;”时,显示表删除成功。当重新执行该表的建表语句时,报错“Table 'app.test_app /* Partition p0 */' already exists” 三、问题分析: 3.1> 原因是GreatSQL 5.7数据库DDL没有原子性,drop表的删除动作没有执行完成; 3.2> 进入数据库“show tables”查看test_app表已不存在; 3.3> 进入数据库所在的目录下,查看test_app表的相关文件。test_app.frm文件已不存在,但是有大量的"test_app#P***.ibd"分区表文件存在。关闭数据库,移除这些分区表文件到其他目录,启动数据库;数据库无法启动,报“无法找到这些分区表文件”的错误; 3.4> 重新创建test_app表时,报“table already exists”错。 3.5> 感觉进入了死胡同,最先想到的直截了当方法是备份APP业务库内除这张表的其他表,删除该数据库后,进行APP业务数据库的恢复,该方法没有测试,觉得太麻烦。 四、问题处理(方法一,测试步骤): 4.1> 新建一个临时库test,依据app库目录里的数据文件名称,修改建表语句后,执行test_app表的建表SQL语句,生成test_app.frm文件; 4.2> 关闭数据库,修改数据库配置文件my.cnf文件的参数为“innodb_file_per_table=OFF”; 4.3> 把临时库test目录下的test_app.frm文件拷贝到业务数据库app目录下,启动数据库; 4.4> 进入业务数据库APP,可以看到test_app表; 4.5> 执行“drop table test_app;”语句,成功删除了表。关闭数据库; 4.6> 进入业务数据库app对应的目录下,test_app.frm文件已不存在,但是有个test_app#P***.ibd分区表文件存在。手工删除该ibd文件。 4.7>修改数据库配置文件my.cnf文件的参数为“innodb_file_per_table=ON”;启动数据库。 4.8> 重新执行test_app表的建表SQL语句。即可成功创建表。 五、问题处理(方法二,客户执行步骤): 5.1> 设置innodb_file_per_table=OFF:set global innodb_file_per_table='OFF'; 5.2> 执行test_app表的建表语句,建表成功。 5.3> 删除test_app表drop table test_app; 5.4> 重启数据库。 5.5> 再执行test_app表的建表语句,建表成功。

    01
    领券