所以我目前正在使用SSIS 2008从旧的Advantage数据库服务器迁移到SQL 2005.旧的Advantage数据库中的一个列是MEMO类型.默认情况下,这会转换为DT_TEXT列.好吧,在新数据库中,我不需要这么大的字段,但可以将其限制为诸如VARCHAR(50)之类的东西.我成功设置了一个派生列转换,使用以下表达式对其进行转换:

(DT_STR,50,1252)[ColumnName]

现在我想更进一步,用空字符串替换所有NULL值.使用ISNULL([ColumnName])?"":(DT_STR,50,1252)[ColumnName]表达式似乎很容易,但问题是OLE DB目标包含以下错误

无法在unicode和非unicode字符串之间进行转换...

显然,整个ISNULL表达式将数据类型转换为Unicode字符串[DT-WSTR].我已经在整个表达式或不同的部分上尝试了各种演员表,但我无法获得与我需要的数据类型相匹配的数据类型.

首先,是否可以将DT_TEXT类型直接转换为unicode？据我所知,演员阵容不会这样.如果没有,有没有办法让表达式工作,以便将NULL值转换为空字符串？

谢谢你的帮助!

我们正在做一个我们计划使用JPA Persistence的项目.我们认为,一旦项目上线,可能需要更改数据模型.

我的疑问是,有哪些不同的策略可以处理这种变化.特别是我有以下问题:

1. 使用更新的JPA类,将它们合并到现有数据库模式中的最佳实践是什么？

2. 使用JPA,是否有任何最佳实践,存档旧数据,更新数据库模式,并再次将数据库迁移到新模式？

3. 有哪些变化(广义上讲)会使这种迁移变得不可能？

我正在将一些数据从一个oracle架构/表迁移到同一数据库上的新架构/表.

迁移脚本执行以下操作:

create table newtable as select
  ...
  cast(ACTIVITYDATE as date) as ACTIVITY_DATE,
  ...
FROM oldtable where ACTIVITYDATE > sysdate - 1000;

如果我查看原始数据,它看起来很好 - 这是一条记录:

select 
  activitydate,
  to_char(activitydate, 'MON DD,YYYY'),
  to_char(activitydate, 'DD-MON-YYYY HH24:MI:SS'),
  dump(activitydate),
  length(activitydate)
from orginaltable  where oldpk =  1067514

结果:

18-NOV-10                 NOV 18,2010                        18-NOV-2010 12:59:15                          Typ=12 Len=7: 120,110,11,18,13,60,16  

迁移的数据,显示数据已损坏:

select 
  activity_date,
  to_char(activity_date, 'MON DD,YYYY'),
  to_char(activity_date, 'DD-MON-YYYY HH24:MI:SS'),
  dump(activity_date),
  length(activity_date)
from newtable
where id =  1067514

结果:

18-NOV-10                 000 00,0000                         00-000-0000 00:00:00                           Typ=12 Len=7: 120,110,11,18,13,0,16   

在35万条记录中,约有5000条显示出此问题.

谁能解释这是怎么发生的？

我的部署策略如下(使用Fabric):

1. 创造一个新的virtualenv
2. 在新的virtualenv中部署新代码
3. 显示维护页面
4. 将当前数据库复制到新数据库
5. 迁移新数据库
6. 将新代码指向新数据库
7. 符号链接当前virtualenv到新的venv
8. 重启服务
9. 删除维护页面

我想快速迭代.现在,大多数代码更改都不包含迁移.此外,数据库正在增长,因此每次部署(通常很小)更改时,通过复制数据库会产生很多开销.为避免复制数据库,我想检查是否存在需要部署的迁移(在步骤4之前).如果没有迁移,我可以直接从第2步到第7步.如果有,我将按照所有步骤进行操作.为此,我需要以编程方式检查是否存在需要部署的迁移.我怎样才能做到这一点？

我目前有一个需要重写的结构,以应对Django-CMS

目前的设置如下

class Video(models.Model):        
    #embed_code_or_url = models.CharField(max_length=2000)
    permalink = models.URLField(verify_exists=True, unique=True, max_length=255, default="http://", validators=[validate_youtube_address])
    thumbnail = models.CharField(max_length=500, blank=True, null=True)
    # Data
    title = models.CharField(max_length=255, blank=True)
    ...

class VideoPlugin(CMSPlugin):
    video = models.ForeignKey(Video)

当我现在将所有字段从中转移Video到VideoPlugin,运行我的模式移植时,我还想在运行迁移时将所有信息从Video传输到VideoPlugin.

有没有人有一个如何实现这一目标的例子？

这是要运行的迁移的开始

class Migration(SchemaMigration):

    def forwards(self, orm):

        # Adding field 'VideoPlugin.permalink'
        db.add_column('cmsplugin_videoplugin', 'permalink', self.gf('django.db.models.fields.URLField')(default='http://', unique=True, max_length=255), keep_default=False)

        # Adding field 'VideoPlugin.thumbnail'
        db.add_column('cmsplugin_videoplugin', 'thumbnail', self.gf('django.db.models.fields.CharField')(max_length=500, null=True, blank=True), keep_default=False)

        # Adding field 'VideoPlugin.title'
        db.add_column('cmsplugin_videoplugin', 'title', self.gf('django.db.models.fields.CharField')(default='', max_length=255, blank=True), keep_default=False)

        ...

非常感谢您的帮助

我们一直在使用Visual Studio数据库项目来维护项目的当前架构,这对于我们在将数据库架构引入新开发机器方面效果很好,但我们还没有用它来升级环境.以前我们使用迁移脚本将您从初始版本带到下一版本,依此类推,直到您处于当前版本,但现在我们希望利用数据库项目的强大功能.

我最近读了Barclay Hill的两篇帖子

在部署期间管理数据运动(第1部分)
在部署期间管理数据运动(第2部分)

其中介绍了从一个版本转到另一个版本时如何进行部署前后脚本,我们已经习惯了很好的效果,但是我现在陷入了一些我无法解决的问题,并感到我错过了.我们有两个不同版本的数据库,但迁移脚本不适用于两者中的较旧版本.以下是我们场景的简化版本.

脚本

版本1

表
1 ColumnABC CHAR(1)

版本2

表1
ColumnXYZ INT

从版本1到版本2的数据移动

预部署脚本检查数据库所处的版本,如果版本为1,则将ColumnABC中的数据放入临时表中.

部署后脚本检查我们现在是否为版本2,并检查是否存在在预部署脚本中创建的临时表,并在将char转换为int后将其放入新列ColumnXYZ中.

版本3

表1
Column123 INT

当我们将数据库从版本1升级到版本2然后升级到版本3时,一切正常.但是,如果我们在版本1上有一个数据库并希望跳转到版本3,则部署后脚本将失败,因为没有ColumnXYZ,因为它现在是Column123.

在旧的迁移方法中,这不会是一个问题,因为部署逐个遍历每个版本,但这不是数据库项目的工作方式.还有其他人经历过这个吗？你是如何处理它并让我错过了一些明显的东西？

我有一个基于opencart的购物车网站..

现在我想把它转换成一个magento网站..

我做了一个新的magento安装.现在我需要将数据从opencart数据库迁移到新的magento数据库

那么,任何人都可以给我表名称,并告诉我成功迁移应该做些什么？

谢谢

在迁移项目期间,我面临着SQL Server中400万条记录的更新.

更新非常简单; 一个布尔字段需要设置为true/1,我输入的是一个必须填充该字段的所有id的列表.(每行一个id)

当谈到这个大小的sql任务时,我不是一个专家,所以我开始尝试包含" WHERE xxx IN ( {list of ids, separated by comma} )"的1 UPDATE语句.首先,我尝试了一百万条记录.在测试服务器上的一个小数据集上,这就像一个魅力,但在生产环境中,这给出了一个错误.所以,我缩短了ID列表的长度几次,但无济于事.

我尝试的下一件事是将列表中的每个id转换为UPDATE语句(" UPDATE yyy SET booleanfield = 1 WHERE id = '{id}'").某处,我读到每隔x行有一个GO是好的,所以我每100行插入一次GO(使用优秀的'sed'工具,从unix移植).

因此,我将400万个更新语句的列表分成每个250.000的部分,将它们保存为sql文件,并开始加载并运行第一个到SQL Server Management Studio(2008).请注意我也尝试过SQLCMD.exe,但令我惊讶的是,这比SQL Studio慢了大约10-20倍.

完成大约需要1.5小时,导致"查询已完成并出现错误".但是,messages-list包含一个很好的列表"受影响的1行"和"0行受影响",后者用于未找到id时.

接下来,我使用COUNT(*)检查了表中更新记录的数量,发现更新语句数量与更新记录数量之间存在数千条记录的差异.

然后我认为这可能是由于不存在的记录,但当我减去输出中"0行受影响"的数量时,有895条记录的神秘缺口.

我的问题:

1. 有没有办法找出"查询已完成但有错误"中的错误描述和原因.

2. 如何解释895记录的神秘差距？

3. 有什么更好或最好的方法来进行此更新？(因为我开始认为我正在做的事情可能非常低效和/或容易出错)

我们有Cassandra集群,每个节点有一个令牌,总共22个节点,每个节点的平均负载为500Gb.它具有SimpleStrategy用于主键空间和SimpleSnitch.

我们需要将所有数据迁移到新数据中心,并在没有停机的情况下关闭旧数据中心.新集群有28个节点.我想要有vnodes.

我正在考虑以下过程:

1. 将旧群集迁移到vnodes
2. 使用vnodes设置新群集
3. 将新群集中的节点添加到旧群集中,并等待它平衡所有内容
4. 将客户端切换到新群集
5. 从旧集群逐个停用节点

但是有很多技术细节.首先,我应该在vnodes迁移后将旧集群洗牌吗？那么,切换到NetworkTopologyStrategy和GossipingPropertyFileSnitch的最佳方法是什么？我想切换到NetworkTopologyStrategy,因为新集群有2个不同的机架,带有独立的电源/网络交换机.

我有一个Cassandra集群(3个节点,所有节点都部署到AWS)我试图迁移到DataStax集群.现在是时候停止自己管理这些节点了.

我有多个生产者和消费者全天都在读取/写入我的Cassandra集群的数据.我没有选择将app/service/proxy放在我的Cassandra集群前面,然后只是干净地翻转开关,以便所有读/写进出我的Cassandra,再到DataStax.因此,没有一种方法可以一次迁移一个表.我还试图为数据的所有生产者/消费者实现零(或接近零)停机时间.一个硬性要求:迁移不能有损.没有丢失的数据!

我认为这里最好的策略是一个四步过程:

1. 不知何故,将DataStax配置为我的Cassandra集群的副本,有效地创建到DataStax的流复制
2. 一旦DataStax完全"赶上"我的Cassandra中的其他节点,让生产者写入我当前的Cassandra集群,但将消费者/读者切换到DataStax(即,重新配置它们以连接到DataStax,然后重新启动它们).不是零停机时间,但我可以忍受简单的重启.(同样,零停机解决方案是首选.)
3. 将生产者切换到DataStax.同样,只有接近零停机时间,因为这涉及将生产者重新配置为指向DataStax,然后需要重新启动以获取新配置.零停机解决方案将是首选.
4. 一旦来自"旧"Cassandra集群的复制流量消耗为零,我们现在就没有"非"新信息,我的非DataStax节点需要写入DataStax.用火来杀死那些节点.

这个解决方案是我能提出的最微创,最接近零停机的解决方案,但假设了以下几点:

• 也许不可能将DataStax视为可以复制到的额外节点(是/否？)
• 也许Cassandra和/或DataStax有一些我不知道的神奇特性/功能,可以比这个解决方案更好地处理迁移; 或者可能有第三方(理想的开源)工具可以更好地处理这个问题
• 我不知道如何监视从"旧"Cassandra节点到DataStax的复制"流量".在我可以安全地关闭+杀死旧节点之前需要知道如何做到这一点(再次,不能丢失数据).

我想我想知道这个策略是否:(1)可行/可行,(2)最佳; 如果Cassandra/DataStax生态系统中有任何功能/工具,我可以利用它来做得更好(更快,零停机时间).