老一辈的DBA们在处理非结构化数据时可能会条件反射的有这么一种思路：将二进制文档、图片等存放于文件系统上，在数据库中记录其元数据，这种经典方案一直持续到Oracle 11g的推出，在SecureFiles的理念得以普及后，一些企业级应用的非结构化数据存储方案有了更多的选择。今天，SQL Server Denali也引入了这个功能，命名为FileTable。 FileTable基于SQL Server 2008引入的FileStream功能进行构建，在概念和功能上都和SecureFiles几乎一致，充分利用了DBMS的优势来管理非结构化数据，同时也打通了文件系统的壁垒，直接通过Windows资源管理器来访问FileTable文件夹。这种特性使非结构化数据的全文索引、SQL操纵文件、基于DBMS的安全机制和快速访问机制等得以轻松的实现。 在SQL Server中启用FileTable的方式非常简单，只需要启用数据库级的非事务型访问(和FILESTREAM的配置是相对独立的)，然后就可以通过SQL Server Management Studio或者简单的TSQL来创建FileTable了： CREATE TABLE DocumentStore AS FileTable WITH ( FileTable_Directory = ’DocumentTable’, FileTable_Collate_Filename = database_default ); GO 在denali(至少到CTP3为止)中，相比其他功能而言，FileTable目前还不支持以下功能： 不支持分区 不支持分发(Replication) Windows中无法进行回滚或恢复等操作(TSQL可以) 自服务数据库(Contained Databases)的支持尚不完善 在备份恢复方面，因为启用非事务型访问，所以无法实现常规意义的基于事务日志的PIT(Point-in-Time)恢复。 对于Windows文件操作，无法进行审计(Audit) 继Oracle和SQL Server之后，估计还会有更多的DBMS会陆续增加类似特性。
Archives for Database
APEX 上传xls文件
上一篇文章介绍了APEX中上传文件的方式，以纯文本文件为例说明了如何对上传的文件进行后续处理。PL/SQL可以直接对纯文本内容进行处理，那么如果直接上传xls二进制文件呢？通常，可以用Java Procedure做这件事，但是自APEX Listener 1.x 发布后，有更简单的方式实现对xls内容的处理。 1.10 版本之后，apex-config.xml 中多了下面这个参数： false 将该参数设置为true则开启excel到collection的转换功能，简单设置步骤如下： 1. 添加File Browse…的Page Item，名字为P1_FILENAME，Storage Type 为 WWV_FLOW_FILES 2. 添加名为UPLOAD的Button Item，Button Request 设置为 xls2collection 运行该页面，选择一个xls后缀的Excel文件，点击UPLOAD按钮即可上传该Excel文件。 上传的文件和数据分别存放在wwv_flow_files和apex_collections中。其中COLLECTION_NAME的默认名称为Page Item的名称，此例中为P1_FILENAME，C001为Excel的TAB页名称，接下来的各字段为表格内容。 SELECT * FROM apex_collections a WHERE a.collection_name = ‘P1_FILENAME’ apex_collections是视图，限制了security_group_id，你需要在应用程序中，并且是当前会话中使用。 删除Collection方式为： apex_collection.delete_collection(p_collection_name => ‘P1_FILENAME’); 详细说明可参考APEX 4.0的API Reference文档中的APEX_COLLECTION章节。 有了APEX Listener，很多事情变得更简单了，当然，除了文档，APEX的文档令人吃惊的简单，很多内容都没有提及。
APEX 4 中的文件上传功能
有一个APEX小应用需要提供Excel数据上传功能，并且要对上传的数据进行后续加工处理，于是就有了下面这段有点通用的代码。 APEX 4.0中上传的存储位置有两个选择，一个是集中式的WWV_FLOW_FILES，一个是自定义的表。对于前者我不喜欢，所有应用上传的文件都存储在一个地方，有些时候管理起来不够方便；如果是自定义的表，每个应用单独存放，那么不论在迁移还是某些维护都相对简单，当然，对于上传功能的设计而言就需要多花几分钟时间了。下面是自定义表的一个例子。 1. 先创建存储表 attach_data blob 二进制数据 attach_mimetype varchar2(255) 文件类型 attach_filename varchar2(255) 文件名 attach_last_update date 上传时间 attach_charset varchar2(128) 字符集 attach_id number 文件ID 一般而言，最好将该表最小化，包含必须的几个字段即可，如果需要和其他表关联，则可以通过ATTACH_ID关联。 2. APEX页面中增加File…上传的item，属性设置如下： 3. 添加提交表单的按钮，提交时触发一次Automatic Row Processing (DML)的Process，设置表名和主键，系统会自动将相关数据（包括上传的文件）插入对应的表中。关于主键ID的自动生成，可以在After header位置增加一个自动fetch row的设置即可。 4. 文件上传功能本身是非常简单的，接下来是针对该上传文件的后续处理。在顺序上，要先有处理上传的Process(就是第3步)，然后再有后续处理的Process。手工在Page Process处再添加一个名为Parsing Attachment(名字随意)的Process，在Source处理加入匿名PL/SQL代码。例如我喜欢直接调用写好的包，那就写上： process_upload.process_file_upload; 这里需要用户首先对Excel做一个另存为文本文件的操作，目前为止，我还没发现可以用PL/SQL来直接操作二进制Excel文件。如果有必要，可以考虑使用Java Procedure对Excel文件进行处理。 附上几段代码： PROCEDURE process_file_upload IS l_blob_data BLOB; l_blob_len NUMBER; l_position NUMBER; l_raw_chunk RAW(2); l_raw_line RAW(32767); l_line [...]
EBS 11i数据库升级(9i->10g)几点事项
最近几日在评估和测试EBS的系统升级(11i升级到R12)，虽然官方的升级文档里介绍的比较详细了，但是依旧会出现一些容易疏忽的问题，这里做一些记录。这里并不是单纯的数据库升级，需要考虑EBS的特殊应用。对于升级方案，标准的有三种： 同时升级数据库和应用。 先升级数据库到10gR2，然后升级应用到R12。 先升级数据库到11gR2，然后升级应用到R12。 其中第2和第3种方案有点类似，都是将整个升级方案划分为两个阶段，只是数据库版本不同。实际上，从技术上看，第1种方案也是两步走，只是在应用层跳过一些过渡性的补丁直接升级到R12。 在数据库升级方面，升级路线主要有下面两种： 路线1: 9.2.0.6 -> 9.2.0.8 -> 11.2.0.1 如果是Solaris系统，则要求系统版本至少为 Solaris 10 Update 6。 路线2: 9.2.0.6 -> 10.2.0.1 -> 10.2.0.4 注：最新patchset是10.2.0.5，只是升级文档依旧停留在10.2.0.4。 从一般认识上讲，Oracle数据库在下一个大版本出来后，上一个版本才被认为是相对更稳定的，所以此处选择第二条路线。 数据库升级方式简单而言有以下几种： DBUA，直接通过图形化工具升级，这个最简单。 Manual，类似于上一种方式，只是手工进行各个步骤的升级操作。 Export/Import 有利于数据表的整理，重构数据库，比如修改字符集、数据文件、表空间参数等，在升级时间上，比DBUA和Manual两种方式都要长。 利用数据复制等技术，升级备用环境后再切换。 由于允许停机，并且暂无特殊的要求，所以这里使用DBUA做升级操作。 在升级之前，建议卸载statspack，并且先解决Invalid Objects的问题。此外，数据库升级后DBLINK需要重建，所以先准备相关重建脚本。下面按照文档步骤升级数据库9.2.0.6 至 10.2.0.4，每个步骤都列在下面，对几个步骤中需要额外关注的地方做了备注。 Verify software versions 检查现在软件版本，基本上应该不会有问题的，留意一下AD版本，最新版本是11i.AD.I.7，不过要求11i.AD.I.6就可以了。 Migrate to Oracle Portal 10g (conditional) Deregister the current database server (conditional) Update application tier [...]
Planning Manager诊断过程和10046事件
在一次Planning Manager性能问题的诊断中，用到了Oracle ERP环境中非常典型的诊断操作和过程，特全程记录于此。 当发现某个程序存在性能问题时，首先当然是快速检查一下SESSION的相关信息，看看主要在执行或等待些什么： SELECT stat.sid, n.name, n.class, stat.value FROM v$sesstat stat, v$statname n WHERE stat.statistic# = n.statistic# AND stat.sid = 121 ORDER BY upper(n.name); 这里观察到bytes received via SQL*Net from client, bytes sent via SQL*Net to client 和 SQL*Net roundtrips to/from client 都在飙升。这对应了两个events：SQL*Net message to client和SQL*Net message from client，这两个事件数值大并不意味着网络状况不好，前者仅仅表示Oracle数据库将数据放入TCP send buffer的时间，而后者表示从客户端接收到反馈指令的时间，两者反映了SQL*Net和数据库之间的时间消耗，而不是网络传输的时间消耗。基于对系统架构的了解，排除SQL*Net的性能问题，那么两个事件预示了什么呢？ SELECT * FROM v$sess_io [...]
