rake db:migrate 挂起 db:schema:dump 步骤答案

【问题标题】：rake db:migrate hangs on db:schema:dump steprake db:migrate 挂起 db:schema:dump 步骤
【发布时间】：2014-04-16 19:41:09
【问题描述】：

执行rake db:migrate 命令时，它会挂在Execute db:schema:dump 步骤上。我正在使用 jruby 1.7.10 和 db gem jdbc-db2 v 9.7。似乎schema.rb 文件已在 db 目录中成功创建，但命令仍然只是挂在该步骤上。

任何关于可能导致此问题的想法都会有所帮助。

【问题讨论】：

你检查过你的数据库的状态吗？与 postgresql 和数据库服务器重新加载有同样的问题已经解决了它
我遇到了同样的问题（rake --trace db:migrate）向我展示了挂起的步骤。我在这里找到了解决方法 - 只是覆盖了 rake 任务 stackoverflow.com/questions/6453267/…

标签： ruby rake jruby database-migration

【解决方案1】：

我刚刚经历了类似的事情，我的 rake 测试越来越慢。我正在使用 Rails 2.0.2、Ruby 1.8.6 和 Oracle 11.2。

问题在于 Oracle 有一个 recycle bin，并且每次运行 rake 测试时表都会被删除并重新创建，所以它会被填满。

为了防止回收站变大，我在准备好测试数据库后添加了一个清除它的步骤。使用以下内容创建文件lib/tasks/databases.rake：

namespace :db do
  namespace :test do
    task :prepare do
      # The Oracle recycle bin fills up and slows down the test preparation.
      ActiveRecord::Base.connection.execute("purge recyclebin")
    end
  end
end

您可能不想在生产数据库中执行此操作，但您没有针对生产数据库运行 db:test:prepare，是吗？

我注意到这个查询运行了很长时间才发现问题：

 SELECT lower(i.index_name) as index_name, i.uniqueness, lower(c.column_name) as column_name
 FROM user_indexes i, user_ind_columns c
 WHERE i.table_name = 'QCS_USERS'
 AND c.index_name = i.index_name
 AND i.index_name NOT IN (SELECT uc.index_name FROM user_constraints uc WHERE uc.constraint_type = 'P')
 ORDER BY i.index_name, c.column_position

查看user_constraints 表，我看到有数千行，即使在我删除了所有表之后，我也看到了回收站的some discussions。

【讨论】：