前事不忘,后事之师,不忘国耻!

 注册  找回密码
 注册

QQ登录

只需一步,快速开始

搜索
查看: 2267|回复: 0

SQL远程数据同步与数据导入的常用方法[原创]

[复制链接]

SQL远程数据同步与数据导入的常用方法[原创]

[复制链接]
ehxz

主题

0

回帖

7251

积分

管理员

积分
7251
2008-1-29 00:33:37 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

×
//blog.csdn.net.chengg0769 转载此行保留 QQ群请加: 6539042(powerbuilder11&SQL)   
在大量数据传递过程,我们经常遇到txt文本到table的import和export 。txt既是通用的形式,也常常是系统之间隔离的最好方法。

这里我们讲如何实现本地数据库和远程数据库的同步。并且达到无人干预,几乎自动化。我的写法和做法不一定正确,首先申明。

1. 远程数据自动定时export到FTP上

2. 本地安装CuteFTP软件,设置帐号密码,然后设置两个文件夹同步。自然是本地同步于远程。同步规格为“只要文件更新日期比现在的新则覆盖”。

3. 计算时间差,即远程文件导出文本的时间点,下载到本地需要的时间,然后在本地设置最合适的启动作业时间。

4. txt文件导入方式,如果是表名固定的话,将remote file的存放目录固定下来,然后在DTS服务里设置DTS包。如123.dts,需要存为文件,便于你拷贝到其它地方。注意:如果拷贝到其它地方时文件路径改变需要编辑修改DTS包;编辑后需要另存一份新的,这样你在调用时不必指名包的版本,比较方便,否则不指名版本的调用会报错。

如果表名和文件名不固定,则唯一的方法是设置procedure来进行处理,使用动态语句来创建新表或分表,然后根据动态的文件名导入相应的文件到对应的数据表里。

这个是比较麻烦的,因为主要是存在数据的分表,有些数据是按月,按旬导出的,就要根据系统计算当前所在的周期,而且要判断当前的日期,看应该导入哪个文件了。当然,执行DTS,bulk insert 语句之前都需要这个文件存在,否则执行会中断。

动态语句麻烦在看起来不直接,而且语句通常比较复杂,我所接触的都在400-1200行左右,有时感觉非常烦燥。里面有大段红色的用引号引起来的语句。几乎无法查阅。非常凌乱。更糟糕的是很多人对这个根本就没有接触,很多人写procedure都很少。

动态语句总是有很多引号(原本有单引号的需改成两个单引号),而且有许多文字拼接。有的还采用参数传入传出,看得人眼花缭乱,变动修改也是十分烦人。所以,详细的说明文字和修改备注是必须的。

判断文件或目录是否存在看下面给出的存储器,你可以直接使用。

/*判断文件是否存在--------------------------------------------------------------------------------------------------------------*/
/* drop procedure pr_filepathexists */
create procedure pr_filepathexists(@parm varchar(200),@filepath smallint,@ret char(1) ='' output)
as
CREATE TABLE #tmp (
FileExists BIT,
isDirectory BIT,
ParentExists BIT)

INSERT INTO #tmp
EXEC master.dbo.xp_fileexist @parm

SELECT @ret = case @filepath when 1 then FileExists when 2 then isDirectory when 3 then ParentExists end

FROM #tmp
select @ret
drop table #tmp
-----------------------------------------------------------------------------------------------------------------------------------------------

当然,按常理,如某个文件在你导入时应该存在,但可能远程服务器出错,未导出该文件。或者要晚一天导出,则你在执行导入时,检测到这个异常,一般应该写入日志,提示管理员处理。按旬执行的语句,你应该重复的检查几次,直到正确导入。必须得给一些宽裕度。

在procedure里,我们基本上可以直接执行DTS或者用bulk insert 来插入,效率还可以。百万级,千万级的数据也没问题。只要CPU足够快,内存足够大。

执行DTS:

SET @dtsname = @dts_path + @dtsname   
SET @SQLcmd = 'dtsrun /F '+ @dtsname
EXECUTE @error = master..xp_cmdshell @SQLcmd

注:依照我的经验,因为dtsrun是一个dos程序,如果你使用循环来执行多个DTS,似乎应该执行完一个DTS包后,休息5S,等待dtsrun.exe消失再执行下一个,这个问题曾困扰我几乎崩溃,就是程序执行时卡在那里很久也执行不完。后来看任务器里发现有多个dtsrun.exe,估计是资源未释放吧。未深究。改用休息5S后,执行很顺利。任务器里只看得到一个dtsrun.exe。

----

执行bulk insert :

set @SQLcmd = 'BULK INSERT charge_transfer FROM '''+ @thiscycle_file + '''  WITH (FIRSTROW = 2,FIELDTERMINATOR = '','',ROWTERMINATOR = ''\n'')'

exec(@SQLcmd)

*注:如果遇到你设置的表栏位比较多,而txt文本的数据栏位比较少(有些栏位需要计算生成),则这个显得稍微复杂。需要格式文件,格式如:

8.0
5
1       SQLCHAR       0       20      ","                       4     calling              Chinese_PRC_CS_AS
2       SQLCHAR       0       20      ","                       5     called               Chinese_PRC_CS_AS
3       SQLCHAR       0       20      ","                       6     startdateendtime     ""
4       SQLINT        0       4       ","                       7     duration             ""
5       SQLINT        0       4       "\r\n"                    8     callcost             ""

col1:宿主文件顺序;col2:宿主文件数据类型;col4:宿主文件字段长度;col5,列分隔符;col6:数据库字段顺序(关键在这,它允许跳过某些列);col7:table的列名;col8:table 列的排序规则,char,varchar必须输入,其它为null.

//20070914: modify    如果你使用txt文本,则col2:宿主文件数据类型全部为SQLCHAR,只是长度根据实际文件而定

通常,我们需要评估导入的效率,所以需要在exec(@SQLcmd)前后抓取时间,等执行完后,计算执行时间,这是有必要的;如果出现错误,需要写入日志,因为这些处理是在后台执行,一般是晚上,唯一的处理方式是报告管理员。对于正常的步骤也需要写入日志,否则我们无法看到程序执行的细节步骤了,对管理和调试都没有好处。

5.单一导入功能的procedure和DTS设置好后,你可以建立一个schedule-procedure在job里定时调用(需开SQL agent),并且要查看调用作业是否成功,要找到中途错误跳出的的问题修改之,否则导入不会继续。当然,我的做法是把DTS的名字。单一的procedure的名字都设置在一个表格里,设置编号,执行先后顺序,执行的时段(一天可能执行多次),这样看是DTS包还是procedure可调用不同的通用调用语句。以后要增加表时,你只要写好存储器,把存储器名字加入这个表即可,这也是一种框架式的设计思路。

6. 导入数据后,再根据需要计算一些中间结果,产生分析报表等,我接触到的系统,有每天同步两次的表,有旬表,有月表,还有星期表,每天更新后,在原表基础上我还增加了大量的附加栏位,比如分局,机房等,我则通过其它计算得到这两个栏位,这样产生报表时,或查询时才会很快。而旬表,月表都是一些最终结果,一般导入,体积太大则分一下表,汇总一下,或校验有没有异常,核算一些如增量啊之类的。算是不复杂。

7. 在执行一系列DTS,procedure之后,在最后,最好执行备份,数据库收缩,优化等。特别提醒的是,你需要关注tempdb的收缩,因为当你有创建临时表的话,这个数据库会变得很大。收缩主要是解决大量数据删除和插入后膨胀得日志,因为日志会变得难以想象的大。注意,日志需要先截断,然后收缩才行。

我现在接触的系统,基本作到完全自动,备份和数据收缩,优化不用客户的管理员操心。如果要让他们为这个系统操心的话,无疑会增加种种难度,他们短期是难于掌握的。

8.如果遇到数据都是G级的情况,内存最好在4G的样子,两年前我是配2颗xeon,现在都是双核,但我还是建议用户用大内存,虽然他们看到花上万块来买几根条子不理解,但效果是好的。对我而言,导入,汇总,索引,复杂分析,报表等,没有内存支撑简直就无法跑得出来。因为数据条数通常在千万条。而且为了跨速处理,都是大批次的处理。当然如果你在1G内存下去作这么大数据的处理,处理完数据,电脑基本就没反映了。

9.特别提示:如果要清除一张表,比如完全更新的话,则使用truncate table 来清理,可以在瞬间搞定,不然你光删除几个百万级的表就够删一晚上了。

10.特别提醒:如果需要导入大量数据,一般需要在导入前drop掉index,等待数据导入后再创建index,否则边插入边创建索引是没有效率的。
免责申明1、欢迎访问本站,本文内容及相关资源来源于网络,版权归版权方所有!本站原创内容版权归本站所有,请勿转载!
2、本文内容仅代表作者观点,不代表本站立场,作者自负,本站资源仅供学习研究,请勿非法使用,否则后果自负!请下载后24小时内删除!
3、本文内容,包括但不限于源码、文字、图片等,仅供参考。本站不对其安全性,正确性等作出保证。但本站会尽量审核会员发表的内容。
4、如本帖侵犯到任何版权问题,请立即告知本站 ,本站将及时删除并致以最深的歉意!客服邮箱:admin@dbabbs.com
您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|Archiver|小黑屋|DBA论坛中国 ( 鲁ICP备20017503号-2 )

GMT+8, 2024-12-4 01:29 , Processed in 0.037062 second(s), 10 queries , MemCached On.

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表