Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Database & SysAdmin
  3. Database
  4. Copy 84 million rows from one table to another table.

Copy 84 million rows from one table to another table.

Scheduled Pinned Locked Moved Database
databasehelpquestiondiscussion
9 Posts 6 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V Offline
    V Offline
    vanikanc
    wrote on last edited by
    #1

    Only issue is the tables are on different servers. What would be the best way? I tried looking at BULK INSERT, looks like you can insert into a file. I tried - insert into A select * from B. It is taking for ever, after almost 3 hours of running the query, I had to kill it. Any thoughts/ideas would be appreciated.

    C R L J P 5 Replies Last reply
    0
    • V vanikanc

      Only issue is the tables are on different servers. What would be the best way? I tried looking at BULK INSERT, looks like you can insert into a file. I tried - insert into A select * from B. It is taking for ever, after almost 3 hours of running the query, I had to kill it. Any thoughts/ideas would be appreciated.

      C Offline
      C Offline
      Chris Meech
      wrote on last edited by
      #2

      You've not mentioned which DB this is for, or if it is for two different vendors perhaps. But I would think for table replication involving 84 million rows, you should be investigating table export/import operations associated with the databases. :)

      Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]

      V 1 Reply Last reply
      0
      • C Chris Meech

        You've not mentioned which DB this is for, or if it is for two different vendors perhaps. But I would think for table replication involving 84 million rows, you should be investigating table export/import operations associated with the databases. :)

        Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]

        V Offline
        V Offline
        vanikanc
        wrote on last edited by
        #3

        Apologise! It is sql server 2005.

        1 Reply Last reply
        0
        • V vanikanc

          Only issue is the tables are on different servers. What would be the best way? I tried looking at BULK INSERT, looks like you can insert into a file. I tried - insert into A select * from B. It is taking for ever, after almost 3 hours of running the query, I had to kill it. Any thoughts/ideas would be appreciated.

          R Offline
          R Offline
          RK KL
          wrote on last edited by
          #4

          I would use incremental loading approach as shown below. It has worked well for me for about 2m rows. http://sqlblog.com/blogs/andy_leonard/archive/2011/12/21/1631.aspx[^] Good luck.

          You can never try. You either do it or you don't.

          1 Reply Last reply
          0
          • V vanikanc

            Only issue is the tables are on different servers. What would be the best way? I tried looking at BULK INSERT, looks like you can insert into a file. I tried - insert into A select * from B. It is taking for ever, after almost 3 hours of running the query, I had to kill it. Any thoughts/ideas would be appreciated.

            L Offline
            L Offline
            Lost User
            wrote on last edited by
            #5

            Is this a one-time operation? If so, I'd simply backup the database, restore it on the other server, and do a "select into" in the night. If the tables need to be in sync, I'd probably go for replication.

            Bastard Programmer from Hell :suss:

            V 1 Reply Last reply
            0
            • L Lost User

              Is this a one-time operation? If so, I'd simply backup the database, restore it on the other server, and do a "select into" in the night. If the tables need to be in sync, I'd probably go for replication.

              Bastard Programmer from Hell :suss:

              V Offline
              V Offline
              vanikanc
              wrote on last edited by
              #6

              Backup and restore sounds like a good idea. Why would I "select * into" again? Also, I read that "select * into" is faster than "insert into select * from"? I guess it would one way, since there will no indexes on the table, right? thanks a lot!

              L 1 Reply Last reply
              0
              • V vanikanc

                Backup and restore sounds like a good idea. Why would I "select * into" again? Also, I read that "select * into" is faster than "insert into select * from"? I guess it would one way, since there will no indexes on the table, right? thanks a lot!

                L Offline
                L Offline
                Lost User
                wrote on last edited by
                #7

                vanikanc wrote:

                Why would I "select * into" again?
                 
                Also, I read that "select * into" is faster than "insert into select * from"?
                 
                I guess it would one way, since there will no indexes on the table, right?

                I haven't compared them, just a habit of dumping new data in it's own table. If you want to speed up the copy further, then try to have the "source"-database on another diskdrive then the "destination" database.

                Bastard Programmer from Hell :suss:

                1 Reply Last reply
                0
                • V vanikanc

                  Only issue is the tables are on different servers. What would be the best way? I tried looking at BULK INSERT, looks like you can insert into a file. I tried - insert into A select * from B. It is taking for ever, after almost 3 hours of running the query, I had to kill it. Any thoughts/ideas would be appreciated.

                  J Offline
                  J Offline
                  jschell
                  wrote on last edited by
                  #8

                  Problem is with the details. Is this a one time operation? Is the target under load? Will there need to be a catch up phase (data in source system that did not get moved the first time.)

                  1 Reply Last reply
                  0
                  • V vanikanc

                    Only issue is the tables are on different servers. What would be the best way? I tried looking at BULK INSERT, looks like you can insert into a file. I tried - insert into A select * from B. It is taking for ever, after almost 3 hours of running the query, I had to kill it. Any thoughts/ideas would be appreciated.

                    P Online
                    P Online
                    PIEBALDconsult
                    wrote on last edited by
                    #9

                    If it's going to be a regular operation I open a Connection to each database, use a DataReader to read from one, and ExecuteNonQuery to INSERT into the other. A major benefit of this technique is that it allows the app to periodically log its progress (and speed in rows per minute) so you're not flying blind. This technique also allows you to catch and ignore selected Exceptions if you like and not have the whole process die.

                    1 Reply Last reply
                    0
                    Reply
                    • Reply as topic
                    Log in to reply
                    • Oldest to Newest
                    • Newest to Oldest
                    • Most Votes


                    • Login

                    • Don't have an account? Register

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • World
                    • Users
                    • Groups