New answers tagged migration
Datapump is one answer. Look at http://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_export.htm#i1007524 - specifically "Transportable Table mode". Moves the metadata, but not the data. You can choose which schemas to include with the SCHEMAS switch, along with the INCLUDE/EXCLUDE parameters.
When you do pg_restore --dbname=mydb --no-owner mydb.dump You are trying to connect to the mydb database which still does not exist. Connect to an existent one and use the --create parameter: pg_restore --dbname=existentdb --no-owner --create mydb.dump http://www.postgresql.org/docs/current/static/app-pgrestore.html
What you are seeing is SQL Server data pages in a backup file. Or a SQL Server data file (.MDF). Either way, is is a collection of 8k data pages. These would be restored or attached to a SQL Server. They are not conveniently readable without a SQL Server install. No SQL Server = no access to the data. Quite simple. If you don't have access to a SQL ...
I know this question is rather old, but I had a similar situation during a migration so I had to comment. What you could do is setup the new 2012 database as an empty shell on your new box. Ensure you have all of your filegroups setup as you would like (striped across several disks and allocated to same sizes). Then script all your schema objects from the ...
It will be faster to transfer the data manually I guess. I would create/move the new db tables inside the old db, select the data from the old old tables inserting into new tables, then move the new tables into new db.
It seems I rarely ever see this recommendation, but Log Shipping is a great method to migrate large databases. If you combine that with turning compression on for the instance (it sounds like you have 2012 since you mentioned Always On), it should be a piece of cake. I've used log shipping to migrate a 2 TB database and several smaller ones. A few ...
if you do not have an enterprise edition, an availability group will not be an option. I would suggest you start up Database mirroring between the two servers and simply failover when the databases are synchronized(Take a backup first) (Don't forget to change your application to connect to the new cloud server at that point because the original database will ...
What version of SQL Server are you using? From SQL Server 2008 onwards, Backup Compression can offer superb rates of compression. I've seen backups pack down to 10% of their original size, so your 100GB+ could be more like 10GB. Of course this really varies depending on the type of data you are storing; XML doesn't pack down too well for example. You ...
One other solution is to backup the ReportServer database from your SSRS backend SQL Server and restore to SQL 2012/2014 and do an in place upgrade. Some Data source connection/password information may be lost unless you backup and restore the master keys as well. Nahci
I found the solution in case anyone else comes across this. The issue lied in the connection string property of the data source. For some reason (maybe standard, I am simply unaware of why) the connection string properties were empty after importing them to the new server. After setting them, they were able to hit the stored procedures and all reports ran ...
if you add a second disk i suggest to put data on to different tablespaces. a tablespace offers additional storage and is VERY easy to use: mkdir /whatever then in SQL: CREATE TABLESPACE myspace LOCATION '/whatever'; ALTER DATABASE x SET TABLESPACE myspace; of course you can also do this for single tables only. and yes, alternatively you can move the ...
Top 50 recent answers are included