Tag Info

New answers tagged

0

This is a simple backup and restore process, with the additional step of making sure you backup the Reporting Services key, so you can restore that as well. A number of links on the internet, but this one is a step by step guide with screenshots, much easier than trying to follow MSDN ...


0

Report Server Database can be backedup and migrated over to the new server in the new network which shouldn't be a trouble. Only problem I see is the Report Server URL, which is not mostly same as before. But, you should still have the same data as before after migration, but, with a different URL after migration.


2

No need to de-install Oracle rdbms software. Just install and configure ASM. If you have enough storage available you can copy your database to ASM using rman.


2

The Oracle docs for 11.2 ASM migration are here: http://docs.oracle.com/cd/E11882_01/server.112/e18951/asm_rman.htm#OSTMG12000 These explain the process that you need to go through to migrate to ASM from filesystem storage.


1

PostgreSQL creates subdirectories named for the PostgreSQL version within each tablespace. So AFAIK pg_upgrade doesn't need to be told to take special action for the tablespaces. It will use the same tablespaces as the original database, but won't conflict because of the use of different subdirectories within the tablespace root. The caveat is that if you ...


1

You use mysqldump. Step 1. Dump your original 32 bit database. mysqldump my32bitdb [options...] > mydb.sql Step 2. Copy the file mydb.sql to your new server Step 3. Load the 32 bit database mysql -u root -p my64bitdb < C:\path\to\mydb.sql With 10GB of data, it shouldn't take much more than ~ 1hr. For reference, see here and here.


0

If you are moving the database (backup on old server and restore on new server) the MVs will come along. Are you creating an empty database on the new server? If so you could use Data Pump to export the MVs from the old and import them into the new. I would opt for using a full RMAN (or filesystem) backup and restore over Data Pump.


1

How are you migrating the database? Copying a database to another server via Backup/Restore or Detach/Attach will include the Assemblies as well as the T-SQL wrapper objects that point to the code in the Assemblies. Using a tool that lets you select object types might require that you at least verify that Assemblies have been selected to migrate. If all of ...


3

That depends. If the assemblies were created and live in the database that is being migrated, then they will go with the database as they are already objects inside of it. If the assemblies were created in other databases that aren't being migrated then they will need to be re-created in the source instance somewhere. For example, if the assembly was made ...


0

Migrating an existing sharded cluster to new hardware If you want to migrate a sharded cluster to new hardware, there is a tutorial in the MongoDB manual: Migrate a Sharded Cluster to Different Hardware Migrating data in an existing sharded cluster to a new cluster There is no officially supported process to migrate documents between two different MongoDB ...


1

cqlsh -k mykeyspace -e 'COPY fromTable(columnNames) TO STDOUT' | head -n -1 | cqlsh -k mykeyspace -e 'COPY toTable(columnNames) FROM STDIN'


0

Its likely with the default encoding used in your Unix/Linux environment. To check which encoding is currently the default one, execute the following: $ echo $LANG en_US In this case, we can clearly see it is not an UTF-8 encoding, the one which the copy command relies on. So to fix this, we just set the LANG variable in example to the following: $ ...


0

I think your plan is largely sound, and is how I handled a similar upgarde (albeit 5.0 > 5.5). What I did was to take a Dump from the Master in the quiet hours like you said, and then set up a new Slave on one of the new 2008r2 boxes. This allows you time to 'play' with the new 5.6 database so you can tweak the config, and make sure the data replicates ...


0

Turns out SSMA just ignores any extra columns you create after migrating the schema - so I could set the default for the project_id columns before migrating data from each Sybase database and have them populated with those defaults.


0

I figured it out. I had to go to Tools > Options > General > Migration and set Extended data migration options to Show. Then I had a new Data Mig... tab for each table, and had to uncheck Truncate SQL Server table and hit Apply individually for each table. Rather laborious when you have a lot of tables... but it worked.


0

To find out more about the PREEMPTIVE_COM_SEQSTRMREAD wait type I would read this great article at sqlauthority, but as Shanky said in the comments, SSIS would more than likely serve you better for a large migration.



Top 50 recent answers are included