Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Upgrade from 2012 to 2017 with Azure SQL DB
#1
Hello,

I am trying to upgrade our ASG RD 2012 database to an ASG RD 2017 database as an Azure SQL DB but I am running into some issues.

I am able to set up the new empty environment using a blank Azure SQL DB with no problems. I then run the upgrade from 2012 to 2017 tool and that runs successfully. When I try to connect to my new 2017 Azure SQL environment, it just hangs at loading data for a while and then throws multiple errors like the one attached. If I leave it sitting long enough and click OK on the errors, it will eventually load but it takes several minutes whereas it takes only seconds to load using a normal sql DB on a server.

Any ideas?

Thanks

   
Reply
#2
Hi and thanks for your post.
Unfortunately I can't tell you right now whats the problem. We have to try to reproduce the problem . I never heard of that problem and I personally have no experience with Azure. So I hope we can give you more input soon, best regards,
Michael
best regards,
Michael -- michael.scholz@asg.com --
Reply
#3
You should check the size of your logs - if you don't need your logs from 2012 you can easily delete the log table - just run the SQL command "TRUNCATE TABLE Logs"
Regards/Gruss
Oliver
Reply
#4
Looks like that decreased the number of error pop ups (they are different ones every time) but it still takes several minutes for ASG to load all the data. Is there a recommended performance level when using Azure SQL DBs?
Reply
#5
What error do you get? Without that information I don't know what is going wrong...

How many objects do you use in your database? After migration you should run "Data Optimizer" because the data structure has changed and 1:1 migration stores a lot of data that is not needed anymore and decrease the performance.
Regards/Gruss
Oliver
Reply
#6
(18-07-2017, 08:30 AM)DevOma Wrote: What error do you get? Without that information I don't know what is going wrong...

How many objects do you use in your database? After migration you should run "Data Optimizer" because the data structure has changed and 1:1 migration stores a lot of data that is not needed anymore and decrease the performance.

One example of an error is in my original post, but they seem to be different every time and sometimes I get no error at all.

How do I find out how many objects are in the database? Data optimizer seems to have helped somewhat but its still much much slower than a non-azure DB.
Reply
#7
You can run Data optimizer more than once because it always optimize one folder level - so if you have more than 2 folder level try to run again.

Detailed Object amount you will get on the database - just run "SELECT COUNT(*) FROM ITEMS" - sure it will be a difference to transfer all data via internet against local area network


So you still get (sometimes) the same error? If Logs table was truncated it should be very fast to add a new log entry - else you could run into a timeout - but this should happen only if you have thousands of log entries in the database
Regards/Gruss
Oliver
Reply
#8
(18-07-2017, 03:34 PM)DevOma Wrote: You can run Data optimizer more than once because it always optimize one folder level - so if you have more than 2 folder level try to run again.

Detailed Object amount you will get on the database - just run "SELECT COUNT(*) FROM ITEMS" - sure it will be a difference to transfer all data via internet against local area network


So you still get (sometimes) the same error? If Logs table was truncated it should be very fast to add a new log entry - else you could run into a timeout - but this should happen only if you have thousands of log entries in the database

Yep, ran the data optimizer several times as we do have a complex folder structure. It is certainly better but still not really usable.

Looks like we have 571 objects. Would that amount cause a significant slow down?

The past few times I've loaded it I have not got any error so looks like that issue might be fixed
Reply
#9
500 objects should be ok - how long does it take for the start? Did you try to use the same database structure on a SQL server in your LAN to see what difference it is?
Regards/Gruss
Oliver
Reply
#10
(19-07-2017, 08:13 AM)DevOma Wrote: 500 objects should be ok - how long does it take for the start? Did you try to use the same database structure on a SQL server in your LAN to see what difference it is?

Takes about a minute to start up in Azure SQL. The exact same DB takes 5 seconds to start up in a normal SQL server.
Reply
#11
Perhaps you can save some seconds with some settings - turn off automatic polling of sessions, turn off tooltips for navigation tree view and ensure that you are using only a minimum of log data (e.g. set all automatic delete options to a low set of entries)
Regards/Gruss
Oliver
Reply
#12
(21-07-2017, 09:20 AM)DevOma Wrote: Perhaps you can save some seconds with some settings - turn off automatic polling of sessions, turn off tooltips for navigation tree view and ensure that you are using only a minimum of log data (e.g. set all automatic delete options to a low set of entries)

We have decided to just keep ASG on-premises for now. Perhaps we will revisit using Azure SQL sometime in the future.
Reply




Users browsing this thread: 1 Guest(s)