在ASP中,用来存取数据库的对象统称ADO(Active Data Objects),主要含有三种对象:Connection、Recordset 、Command Connection:负责打开或连接数据 Recordset:负责存取数据表 Command:负责对数据库执行行动查询命令
用ASP连接DBF、DBC、MDB、Excel、SQL Server型数据库的方法: 一、ASP的对象存取数据库方法 在ASP中,用来存取数据库的对象统称ADO(Active Data Objects),主要含有三种对象:Connection、Recordset 、Command Connection:负责打开或连接数据 Recordset:负责存取数据表 Command:负责对数据库执行行动查询命令 二、连接各数据库的驱动程序 连接各数据库可以使用驱动程序,也可以使用数据源,不过我建
X# 备受关注,你不知道如何入门?本白皮书将引导您构建自己的第一个 X# 应用程序。我们将一个示例 FoxPro 程序逐步转换为 X#,并演示如何将我们现有的 VFP 技能转移到 X# 的范例中。
互联网开端的时候流行的技术是Web1.0,也就是又当爹又当妈,前端与后端代码都混在一起,至今还有一个VFPer一上手就把ASP那套混合代码写在HTML中当做真理,可不知道现在HTML现在已经进化到小程序状态了。
项目:asp.net zero 4.2.0 .net core(1.1) 版本 我们做项目的时候可能会遇到需要提供api给app调用,ABP动态生成的WebApi提供了方便的基于JWT标准的Token访问方式供我们访问API,不用在代码上做任何改动,很方便有木有! 一.什么是JWT Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般
《Oracle一个诡异的临时表空间不足的问题》中提到对临时表空间执行shrink space的操作,以前一直理解只有对表能做shrink space的操作,但从官方文档看,11g开始,就可以对临时表空间执行相同的操作。
对于只读表空间,只需要在第一备份时进行备份,在以后的备份中不需要再对备份过的只读表空间进行备份。
https://blog.csdn.net/tianlesoftware/article/details/5006580
其实利用OS拷贝也可以联机操作,不关闭数据库,但是只针对可以OFFLINE的数据文件,步骤如下所示:
在运维操作过程中会出现一些失误,针对在使用ASM磁盘管理下,给表空间添加数据文件,添加的数据文件不符合创建规则,因此需要对数据文件进行rename操作,关于使用文件系统的rename操作网上已经有很多,在此不在多讲。
在服务器上面建好共享文件夹 \\newserver\dbf 里面放一个DBF,文件夹和DBF 都将权限设为EveryOne读写。
作者简介 胡中豪 云和恩墨西区交付工程师,多年一线 DBA 经验,曾服务于运营商、电网、政府行业、银行等行业客户;擅长数据库故障处理、性能优化、实施升级 本文由恩墨大讲堂147期线上分享整理而成。课程
在Java开发中,有时需要读取DBF(dBase文件)格式的数据文件,而这些文件通常采用GBK(简体中文)编码。本文将介绍如何使用Java读取采用GBK编码的DBF文件。
如果执行了rm -rf操作删除了所有的基于FS的数据文件,但是数据库还处于OPEN状态,那么,在这种情况下如何快速地恢复数据库呢?这里的前提条件是没有任何可用的RMAN备份、数据库冷备份等,也就是说,没有任何备份。在这种情况下可以通过系统的文件句柄号来恢复数据文件。整个恢复过程可以简单分为如下几步:
Oracle 12c开始提供了多租户数据库的功能,对于不同PDB的复制,可以通过克隆,非常便捷地实现。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
关于移动数据库文件,之前写了一篇博文,http://blog.itpub.net/23718752/viewspace-1127910/ 但是在备库中还是有一些的差别。最近因为对备库做了一些规划,新增加了几个分区,想把数据库的一部分文件放到SSD上。所以这个时候在现有的备库基础上需 要移动备库的数据库文件。这里就不局限于数据文件了,不过目前的测试情况来说,还是数据文件是重点,还是主要以数据文件为例。 在备库中目前尝试了两种方式,可以采用rename datafile的方式或者使用rman的方式,对于日
灾备库通过源库的全备archive文件做完全库恢复后,拿到源库的archive日志在灾备库执行recovery恢复时报错:
--====================== -- 只读表空间的备份与恢复 --====================== 一、只读表空间的特性 使用只读表空间避免对静态数据的频繁备份 当使用alter tablespace tbs read only时,数据文件会执行检查点进程(将所有脏缓冲区的内容写至磁盘), 当前的SCN号会被标注,同时存储了SCN的数据文件头部被冻结.控制文件内也会记录该数据文件的冻结信息。 可以清除只读表空间的对象 二、只读表空间的备份 一般情况下,只读表空间只需要进行一次备份,即当表空间状态发生改变时应立即进行备份 可以使用OS系统cp命令来备份或RMAN进行备份只读表空间 使用RMAN时建议启用备份优化选项 RMAN> CONFIGURE BACKUP OPTIMIZATION ON; 只读表空间不支持热备 SQL> alter tablespace tbs1 begin backup; alter tablespace tbs1 begin backup * ERROR at line 1: ORA-01642: begin backup not needed for read only tablespace 'TBS1' 三、只读表空间的还原与恢复 还原与恢复只读表空间的问题在于控制文件如何控制只读表空间,分为下列三种情况: --------- --------------- ---------------- ------------------------------------- case backup 1 crash status recovery --------- --------------- ---------------- ------------------------------------- case 1 Read-Only Read-Only 将备份的只读表空间复制到目的地(Restore) case 2 Read-Only Read-Write 先Restore backup1,后recover(applied log ) case 3 Read-Write Read-only 先Restore backup1,后recover(applied log ) 只读表空间恢复时需要考虑的问题 重建一个控制文件时 重命名数据文件时 使用一个备份的控制文件时 下面对表空间tbs1置为只读后对比前后生成的重建控制文件的脚本
总结了一下,在归档和非归档的场景下,ora-01145这个错误可能有如下三种情况: 1.off line tablespace --在非归档模式下尝试ofline 数据文件 SQL> alter tablespace tools offline immediate; alter tablespace tools offline immediate * ERROR at line 1: ORA-01145: offline immediate disallowed unless media recover
环境:RHEL 5.4 + Oracle 11.2.0.3 背景:数据库没有备份,数据库文件被误操作rm,此时数据库尚未关闭,也就是对应句柄存在,如何快速恢复?
今天在做一些演示的时候,在虚拟机上装了两套数据库软件,10g和11g的。还是在演示普通数据文件迁移的时候还是碰到了一些意料之外的问题,从当时的情况来看感觉还是比较诡异的,所以马上切换到另外一套环境去试验就没有任何问题了。对于这个问题事后进行了分析,发现还是一些简单常规的错误,自己还是对一些细节没有掌握好, 本来对于普通数据文件的迁移流程是很简单的,在数据库open状态就可以迁移, 基本步骤如下: alter tablespace xxxx offline; cp datafiles alter ta
一位朋友说他们压测的应用,前几天都正常,昨天执行的时候,报了如下错误,但是今天没出现,DBA说他们某条SQL占用临时表空间太多了,昨天还给扩了10个G的临时表空间容量,
移动数据文件/home/oracle/cjctbs02.dbf到/u01/app/oracle11/oradata/chendb/cjctbs02.dbf
可参考:Online Move Datafile in Oracle Database 12c Release 1 (12.1)
ALTER TABLESPACE TS_DD_LHR DROP DATAFILE n; --n为数据文件号
众所周知我们的Data Guard数据同步是基于日志流的。所以在主库执行nologging操作是不被允许的。这也就是为什么我们需要在配置Data Guard阶段需要使用Force Logging。但是这也会带来很多问题(SQL执行效率),例如:当我们使用数据泵进行迁移时我们希望最少停机时间完成,这时候我们就可能会考虑到以最小日志导入的方式以加快导入速度,然后重新同步备库。
SYSAUX表空间是在10g之后引入的一个新的表空间,主要用于减轻对SYSTEM表空间的压力而作为SYSTEM表空间的辅助表空间。
闪回数据库这个特性在很多Oracle DBA眼里就是鸡肋特性,因为谁会因为恢复数据而需要在主库闪回,最后可能丢掉更多的数据,这个观点没错。 但是如果是备库呢,这个特性就顺利成章的满足了绝大多数的恢复需求,无论你是truncate,还是一些drop table的操作都是可以轻而易举的恢复。所以更多的时候我们其实更偏爱于Data Guard基础上的这种数据恢复方式,而原本的逻辑备份exp,expdp,物理备份RMAN就显得有些臃肿了。 拿一个真实的小案例来说明,有一次因为数据查询的SQ
背景:在一次xtts的测试中遇到因源库数据文件名称包含特殊字符导致表空间全量备份缺失文件,之所以说是诡异现象,是因为xtts的全备日志不报任何错误,在恢复阶段才发现缺少文件,这个缺陷比较隐晦,尤其在迁移的表空间较多的场景下,不注意的话很难第一时间发现。 环境:客户环境是AIX 5.3 + Oracle 10.2.0.3,使用xtts脚本2.0版本,本文在测试环境OEL 5.7 + Oracle 10.2.0.5 下,使用xtts脚本3.0实验,同样可以重现这个现象,说明是普遍现象。
由于历史的原因,我国的上交所和深交所使用的还是dbf文件来进行行情数据的分发,关于卫星报盘系统,可以参考:http://maltig.itpub.net/post/12165/195151 这个博客中关于证券公司信息化的文章写的还是相当不错的。上交所使用的是show2003.dbf文件,而深交所使用的是SJSHQ.DBF,这种文件可以使用Visual FoxPro直接打开,查看其内容。接下来说说怎么使用C#读取其中的数据。
临时表在日常工作中可能使用比较多,但是大家都对临时表相关的一些知识了解比较少。我们来简单说数理一下。 首先是临时表空间,临时表都存储在临时表空间中,对于临时表空间,从数据库中查询数据字典就能够很清楚的看到,临时表空间是nologging的,也就是临时表也是nologging的。 SQL> select tablespace_name,logging from dba_tablespaces; TABLESPACE_NAME LOGGING -----------------
因为最近需要做一个测试,就顺手搭建了一套简单的dg环境。不过碰到了一些小问题。 数据库环境是11gR2,备库是开在open状态,配置了dg broker,一切都很快完成了。备库状态为"READ ONLY WITH APPLY"当然这是期望之中ADG的状态。 然后在主库需要做一些配置,准备创建几个表空间 先创建了一个表空间 create tablespace testdata datafile '/DATA/app/oracle/oradata/test04/testdata01.dbf' size 100
最近总是需要进行xml的相关操作。 不免的要进行xml的读取修改等,于是上网搜索,加上自己的小改动,整合了下xml的常用操作。 读取XML配置文件 首先我们需要通过DocumentBuilderFactory获取xml文件的工厂实例。 DocumentBuilderFactory dbf=DocumentBuilderFactory.newInstance(); dbf.setIgnoringElementContentWhitespace(true); 创建文档对象
首先在运行的库中得到数据库运行的所有的物理文件位置,然后在计划内关闭数据库(shutdown)
Oracle数据库的存储结构分为物理存储结构和逻辑存储结构两种,分别描述了在操作系统中和数据库系统内部数据的组织和管理方式。
今天创建了一些表空间,准备做data guard来看看效果。 为了方便起见,我用gridcontrol来做,主库也开了Omf,省去了好多步骤。 一路点下来,就等gc的那个状态变成对号了,结果装了近20分钟,alert日志开始报错。 ******************** WARNING *************************** The errors during Server autobackup are not fatal, as it is attempted after sucess
在dba的工作中,备份是一切工作的基础。如果没有备份,本来很简单的恢复工作也会难上加难,如果业务数据要求很高,造成数据的丢失或者损坏,就是重大事故了。 使用rman备份或者做一个完整的系统级备份也是很重要的,如果在特定的场景下,没有备份,如果还能恢复,那就太幸运了。 当数据库中的某个数据文件误删的时候,如果数据库还没有重启的时候,还是能够做一些工作的。因为文件对应的句柄还没有释放。我们可以从里面找到一个镜像的备份实现我们的数据恢复。一定注意这种恢复不一定是完全的数据恢复,如果在数据文件删除的瞬间,有开启的事
本文作者系大连健哥、 POSTGRESQL、ORACLE 数据库资深从业人员、IT 技术的深度爱好者。相信科学改变人类、技术创造未来。个人主页:https://www.cnblogs.com/gaojian/,经其本人授权发布。
自己手头有一套dataguard环境,因为也有些日子没有用了,结果突然心血来潮准备启动起来学习一下,突然发现在敲了命令 recover managed standby database disconnect from session之后,命令运行正常,但是后台却报了ora错误。 Sat Jun 27 23:16:39 2015 Recovery Slave PR00 previously exited with exception 1157 Errors in file /u02/dg11g/diag/rd
今天碰到了一个dataguard在10gR2的bug,不管怎么样确实是在特定的时间做了特定的操作结果碰到了特定的问题。 这个问题是在10gR2的版本10.2.0.4.0的一个库中出现的,在做巡检的时候发现表空间使用率已经很高了,就准备加一些数据文件把这个问题给修复了,按理说这也是一个常规操作,没有什么可圈圈点点的地方。 但是添加完数据文件之后,过了一会,就收到报警说备库出了点问题,自己还纳闷到底是什么原因导致的,带着疑问使用dgmgrl来查看了一下。 DGMGRL> show configuration;
Case:需要给一个现有的shp数据创建一个字段,并将属性表中原有的一个文本类型的属性转换为整型后填入新创建的字段。
① 该语句会删除磁盘上的文件并更新控制文件和数据字典中的信息,删除之后的原数据文件序列号可以重用。
2.数据文件alter database rename file '' to '';
SQL> alter tablespace yhqt read only; SQL> alter tablespace yhqt read write;
注意,上面语句中,制定数据文件路径的时候,一定要使用单引号,否则会出现“ORA-00972: identifier is too long”的错误。
领取专属 10元无门槛券
手把手带您无忧上云