11 个解决方案
#1
写个存储，再设置一个SQL JOB就可以做到的
#2
写一个存储过程利用SQL代理（作业） 定期执行即可
存储过程包含几块：
1： 最好先做一个数据库的完整备份，万一出错还能恢复
2： 使用链接服务器或者远程即席查询（openrowset）将数据备份到历史库
3： 删除本地已备份数据（例如：delete from table where [time] <= dateadd(day,-7,getdate())）
存储过程包含几块：
1： 最好先做一个数据库的完整备份，万一出错还能恢复
2： 使用链接服务器或者远程即席查询（openrowset）将数据备份到历史库
3： 删除本地已备份数据（例如：delete from table where [time] <= dateadd(day,-7,getdate())）
#3
你可以这样
1.写个存储过程：把你要想转移的表全部录入里面，定义一个值例如100W当某些表的数量大于这个值的时候就开始数据转移
2.定义一个JOb，每天某个是几点运行这个存储过程，也可以是每个礼拜，具体看你的每天数据量的大小
1.写个存储过程：把你要想转移的表全部录入里面，定义一个值例如100W当某些表的数量大于这个值的时候就开始数据转移
2.定义一个JOb，每天某个是几点运行这个存储过程，也可以是每个礼拜，具体看你的每天数据量的大小
#4
用SQL的存储过程和作业就可以满足这个需求
#5
大家没理解 我的意思 业务人员不会玩SQL 写个小工具给他们使用 他们想转移就转移
我原计划是 先把正式库的数据导入到Access 数据库， 在把Access数据库导入到历史数据库。
我想听听大家有其他的思路没
我原计划是 先把正式库的数据导入到Access 数据库， 在把Access数据库导入到历史数据库。
我想听听大家有其他的思路没
#6
个人建议 写个job或者程序定时做：
1.初始化状态时候 保留一份数据库的mdf,ldf文件
2.主服务器每天定点分离mdf,ldf文件
3.传输主mdf,ldf文件到从服务器
4.从服务器附加mdf,ldf文件(根据日期新命名这个数据库 )
5.主服务器附加初始化的mdf,ldf文件
1.初始化状态时候 保留一份数据库的mdf,ldf文件
2.主服务器每天定点分离mdf,ldf文件
3.传输主mdf,ldf文件到从服务器
4.从服务器附加mdf,ldf文件(根据日期新命名这个数据库 )
5.主服务器附加初始化的mdf,ldf文件
#7
写成批处理文件才能实现想处理就处理的功能。
#8
最好别让你的业务人员无操作，要不搞的一团糟
你说的想导就导不想导就不弄，这个肯定会杯具，出错了还找你。
这种应该是开发设定一个合理 规范的 方案，不能太随意了。
#9
小弟是新手 求个存储过程的例子
#10
http://www.cnblogs.com/studyzy/archive/2009/04/13/1434406.html
#11
让业务人员想转移就转移正式机的数据？你确定要提供这样的功能？正式机的数据是企业最宝贵的财富之一，其他公司都是想尽方法不让别人随便碰的。
我觉得你可以这样，写个存储过程，首先判断业务人员的权限，然后只能提供该业务人员名下的数据，然后可以通过链接服务器直接导入到其他服务器；如果链接服务器你不能事先确定，也可以让业务人员提供，你在存储过程里使用SQL代码来创建，当然还有目标服务器的账户信息。
另外我强烈建议你不要让业务人员有接触到正式机数据的机会，你可以弄个中间数据库，或者是查询数据库，只给业务人员查询的权限，让他们去搞。搞出事情来大不了删掉重建。
正式机（生产机）越少人接触越好，实在要用，给的权限也越小越好。
我觉得你可以这样，写个存储过程，首先判断业务人员的权限，然后只能提供该业务人员名下的数据，然后可以通过链接服务器直接导入到其他服务器；如果链接服务器你不能事先确定，也可以让业务人员提供，你在存储过程里使用SQL代码来创建，当然还有目标服务器的账户信息。
另外我强烈建议你不要让业务人员有接触到正式机数据的机会，你可以弄个中间数据库，或者是查询数据库，只给业务人员查询的权限，让他们去搞。搞出事情来大不了删掉重建。
正式机（生产机）越少人接触越好，实在要用，给的权限也越小越好。
#1
写个存储，再设置一个SQL JOB就可以做到的
#2
写一个存储过程利用SQL代理（作业） 定期执行即可
存储过程包含几块：
1： 最好先做一个数据库的完整备份，万一出错还能恢复
2： 使用链接服务器或者远程即席查询（openrowset）将数据备份到历史库
3： 删除本地已备份数据（例如：delete from table where [time] <= dateadd(day,-7,getdate())）
存储过程包含几块：
1： 最好先做一个数据库的完整备份，万一出错还能恢复
2： 使用链接服务器或者远程即席查询（openrowset）将数据备份到历史库
3： 删除本地已备份数据（例如：delete from table where [time] <= dateadd(day,-7,getdate())）
#3
你可以这样
1.写个存储过程：把你要想转移的表全部录入里面，定义一个值例如100W当某些表的数量大于这个值的时候就开始数据转移
2.定义一个JOb，每天某个是几点运行这个存储过程，也可以是每个礼拜，具体看你的每天数据量的大小
1.写个存储过程：把你要想转移的表全部录入里面，定义一个值例如100W当某些表的数量大于这个值的时候就开始数据转移
2.定义一个JOb，每天某个是几点运行这个存储过程，也可以是每个礼拜，具体看你的每天数据量的大小
#4
用SQL的存储过程和作业就可以满足这个需求
#5
大家没理解 我的意思 业务人员不会玩SQL 写个小工具给他们使用 他们想转移就转移
我原计划是 先把正式库的数据导入到Access 数据库， 在把Access数据库导入到历史数据库。
我想听听大家有其他的思路没
我原计划是 先把正式库的数据导入到Access 数据库， 在把Access数据库导入到历史数据库。
我想听听大家有其他的思路没
#6
个人建议 写个job或者程序定时做：
1.初始化状态时候 保留一份数据库的mdf,ldf文件
2.主服务器每天定点分离mdf,ldf文件
3.传输主mdf,ldf文件到从服务器
4.从服务器附加mdf,ldf文件(根据日期新命名这个数据库 )
5.主服务器附加初始化的mdf,ldf文件
1.初始化状态时候 保留一份数据库的mdf,ldf文件
2.主服务器每天定点分离mdf,ldf文件
3.传输主mdf,ldf文件到从服务器
4.从服务器附加mdf,ldf文件(根据日期新命名这个数据库 )
5.主服务器附加初始化的mdf,ldf文件
#7
写成批处理文件才能实现想处理就处理的功能。
#8
最好别让你的业务人员无操作，要不搞的一团糟
你说的想导就导不想导就不弄，这个肯定会杯具，出错了还找你。
这种应该是开发设定一个合理 规范的 方案，不能太随意了。
#9
小弟是新手 求个存储过程的例子
#10
http://www.cnblogs.com/studyzy/archive/2009/04/13/1434406.html
#11
让业务人员想转移就转移正式机的数据？你确定要提供这样的功能？正式机的数据是企业最宝贵的财富之一，其他公司都是想尽方法不让别人随便碰的。
我觉得你可以这样，写个存储过程，首先判断业务人员的权限，然后只能提供该业务人员名下的数据，然后可以通过链接服务器直接导入到其他服务器；如果链接服务器你不能事先确定，也可以让业务人员提供，你在存储过程里使用SQL代码来创建，当然还有目标服务器的账户信息。
另外我强烈建议你不要让业务人员有接触到正式机数据的机会，你可以弄个中间数据库，或者是查询数据库，只给业务人员查询的权限，让他们去搞。搞出事情来大不了删掉重建。
正式机（生产机）越少人接触越好，实在要用，给的权限也越小越好。
我觉得你可以这样，写个存储过程，首先判断业务人员的权限，然后只能提供该业务人员名下的数据，然后可以通过链接服务器直接导入到其他服务器；如果链接服务器你不能事先确定，也可以让业务人员提供，你在存储过程里使用SQL代码来创建，当然还有目标服务器的账户信息。
另外我强烈建议你不要让业务人员有接触到正式机数据的机会，你可以弄个中间数据库，或者是查询数据库，只给业务人员查询的权限，让他们去搞。搞出事情来大不了删掉重建。
正式机（生产机）越少人接触越好，实在要用，给的权限也越小越好。