oracle 从本地服务器读取CSV文件的数据，插入到数据表里。数据文件可能是多个比如table1_2016-06-03.csv

你的问题非常简单：

1、存储过程设置为只读取一个文件，存储过程设置传入两个参数，为文件路径和文件名。

2、写个脚本，列出文件名，把这些文件一个一个的送给存储过程处理。

给你个读文件存储过程存储过程：

PROCEDURE read_file(loc_in IN VARCHAR2, file_in IN VARCHAR2)
IS
file_handle UTL_FILEFILE_TYPE;
NewLine     VARCHAR2(1024);
v_NBRCH TESTNBRCH%TYPE;
v_NACNT TESTNACNT%TYPE;
v_ONAME TESTONAME%TYPE;
BEGIN
   file_handle := UTL_FILEFOPEN (loc_in, file_in, 'R');
    LOOP
    BEGIN
        UTL_FILEGET_LINE(file_handle,NewLine);
    EXCEPTION
      WHEN NO_DATA_FOUND THEN
      --跳出系统出口
         UTL_FILEFCLOSE(file_handle);
           EXIT;
      WHEN OTHERS THEN
         UTL_FILEFCLOSE(file_handle);
           RETURN;
    END;
    --这里是处理读出一行数据，分离出每个域到你的变量里面去。
    v_NBRCH:=TO_NUMBER(SUBSTR(NewLine,1,7));
    v_NACNT:=TO_NUMBER(SUBSTR(NewLine,9,9));
    v_ONAME:=SUBSTR(NewLine,19,10);
    --插入数据库
    INSERT INTO TEST(NBRCH,NACNT,ONAME) VALUES(v_NBRCH,v_ROWN,v_ONAME);
    COMMIT;
END LOOP;
END;

如果运行读不到数据或出错，请使用Oracle dba登录，初始化系统变量，然后重启Oracle

ALTER SYSTEM SET UTL_FILE_DIR=;

您在更新SQL Server 2019时遇到“无法为该请求检索数据”错误，这可能是由于各种原因导致的，例如：
1 服务器连接问题：可能您的计算机和 SQL Server 数据库服务器之间发生连接故障，导致无法访问数据库系统。
2 权限不足：如果您没有足够的系统权限，就可能无法执行一些必要的 *** 作来完成更新过程，导致错误。
3 修改过默认设置：如果您修改了SQL Server数据库设置等一些默认设置，可能会与更新进程不兼容，导致错误。
针对此问题，以下是一些建议方法：
1 检查您的计算机和SQL Server数据库服务器之间的连接是否正常，并确保网络通畅。
2 检查您所使用的账户是否有足够的权限来执行此次更新。如果权限不足，可以通过提升账户权限（或者新建具备Install SQL Server权限的本地管理员账户）并重新启动SQL Server安装程序来解决问题。
3 如果您在安装过程中更改了默认设置和配置，则请恢复默认设置并重试。
4 检查您使用的SQL Server版本是否为适用于目前应用程序的版本。如果是，则建议先卸载并重新安装相同版本，再进行更新尝试。
如果以上方法都无法解决问题，可以参考SQL Server错误日志文件的详细错误信息并搜索相关解决方案。如果问题无法解决，建议您联系SQL Server技术支持人员以获得更多帮助。

简单介绍两种方法：
1、在数据库的ACL中把这个用户加到具有”读者“权限的角色中
2、通过编写程序，在数据库的所有文档中添加一个”读者域“，然后把这个用户的全名添加该域中

2000万的数据，确实不小了，楼主的配置，即使上到自强服务器，意义也不大。而2000万短时间无法寄希望于索引得优化，
唯一能作的，最好编写一个id，分段查询，这样以避免sql超时，以及太多内存消耗情况。存储过程对于这种简单的检索，意义也不是很大
上sql集群可能解决问题，但是那毕竟不是我们所能承受的，尤其是一般企业和单位。
mark并学习，等待高手出现！！！！！！！！！！！！！！！！！！！！！

本文中的数据平台已迭代三个版本，从头开始遇到很多常见的难题，终于有片段时间整理一些已完善的文档，在此分享以供所需朋友的。实现参考，少走些弯路，在此篇幅中偏重于ES的优化，目前生产已存储百亿数据，性能良好，关于HBase，Hadoop的设计优化估计有很多文章可以参考，不再赘述。

项目背景：在一业务系统中，部分表每天的数据量过亿，已按天分表，但业务上受限于按天查询，并且DB中只能保留3个月的数据(硬件高配)，分库代价较高。

改进版本目标：

谈到优化必须能了解组件的基本原理，才容易找到瓶颈所在，以免走多种弯路，先从ES的基础结构说起(如下图)：

一些基本概念:

ES依赖一个重要的组件Lucene，关于数据结构的优化通常来说是对Lucene的优化，它是集群的一个存储于检索工作单元，结构如下图：

在Lucene中，分为索引(录入)与检索(查询)两部分，索引部分包含 分词器、过滤器、字符映射器 等，检索部分包含 查询解析器 等。一个Lucene索引包含多个segments，一个segment包含多个文档，每个文档包含多个字段，每个字段经过分词后形成一个或多个term。

通过Luke工具查看ES的lucene文件如下，主要增加了_id 和 _source字段:

Lucene 索引文件结构主要的分为：词典、倒排表、正向文件、DocValues等，如下图:

Lucene 随机三次磁盘读取比较耗时。其中fdt文件保存数据值损耗空间大，tim和doc则需要SSD存储提高随机读写性能。
另外一个比较消耗性能的是打分流程，不需要则可屏蔽。

关于DocValues：

倒排索引解决从词快速检索到相应文档ID, 但如果需要对结果进行排序、分组、聚合等 *** 作的时候则需要根据文档ID快速找到对应的值。

通过倒排索引代价缺很高：需迭代索引里的每个词项并收集文档的列里面 token。这很慢而且难以扩展：随着词项和文档的数量增加，执行时间也会增加。Solr docs对此的解释如下：

在lucene 40版本前通过FieldCache，原理是通过按列逆转倒排表将（field value ->doc）映射变成（doc -> field value）映射，问题为逐步构建时间长并且消耗大量内存，容易造成OOM。

DocValues是一种列存储结构，能快速通过文档ID找到相关需要排序的字段。在ES中，默认开启所有(除了标记需analyzed的字符串字段)字段的doc values，如果不需要对此字段做任何排序等工作，则可关闭以减少资源消耗。

ES中一个索引由一个或多个lucene索引构成，一个lucene索引由一个或多个segment构成，其中segment是最小的检索域。

数据具体被存储到哪个分片上：shard = hash(routing) % number_of_primary_shards

默认情况下 routing参数是文档ID (murmurhash3),可通过 URL中的 _routing 参数指定数据分布在同一个分片中，index和search的时候都需要一致才能找到数据，如果能明确根据_routing进行数据分区，则可减少分片的检索工作，以提高性能。

在我们的案例中，查询字段都是固定的，不提供全文检索功能，这也是几十亿数据能秒级返回的一个大前提：

1、ES仅提供字段的检索，仅存储HBase的Rowkey不存储实际数据。
2、实际数据存储在HBase中，通过Rowkey查询，如下图。
3、提高索引与检索的性能建议，可参考官方文档（如 >