in reading about database mirroring: "Unlike replication, which works at the logical level, database mirroring works at the level of the physical log record. "
that does that mean? "logical level" and "level of physical log record" ?
Logical replication means copying the actual SQL statements to a log.
For example UPDATE foo SET x = 1; is like 20 characters and one statement.
With logical replication you issue that on each server.
Physical replication usually looks at the actual blocks the database files occupy, and when those blocks change the database ships the modifications in delta, or the entire block to another server.
In the above example of an unbounded SET that would be shipping the entire database.
PostgreSQL has both methods. Some databases only support physical replication.
PostgreSQL does physical replication with WAL logs.
I am looking to convert my SQL Server 2014 Express Database to Azure SQL Database.
My SQL Server database was automatically converted from Oracle a number of years ago, and needs the sysdb database as a dependency to provide user defined functions that emulate Oracle functions.
I ran the Data M...
@George.Palacios Yes sysdb is part of an extension pack and just makes code using oracle functions woork
> The SSMA extension pack adds the databases, sysdb and ssmatesterdb, to the specified instance of SQL Server. The database sysdb contains the tables and stored procedures that are required to migrate data, and the user-defined functions that emulate Oracle system functions. The ssmatesterdb database contains the tables and procedures that are required by the Tester component.
I would think he could just use the generate scripts wizard to script the definitions of those and then run the script in his own database but I'm not sure
Depends if the oracle code calls function()or sysdb..function (I would expect the former) but things like select from sysdbwould still fail if he just copied over the objects to his own database
He could test that himself on a DEV box fairly easy I would think
@ConcernedOfTunbridgeWells Most likely a schema lock as @George.Palacios said. There are other more esoteric causes but you should start by checking to see if the query you are attempting to compile is blocked.
@PaulWhite Migating off 2008 R2. We're profiling the source.
@PaulWhite It's hitting another database through synonyms and shredding stuff out of an XML field. Could either of those be generating spurious schema locks?
I can't see anything on the server that could be holding schema locks.
@ConcernedOfTunbridgeWells Are you certain you requested an estimated execution plan? That's an awful lot of logical reads. If you are sure, I would say a synchronous statistics update is in progress on one or more large tables.
> If the statistics update takes a long time (due to a large table and\or busy system), there is no easy way to determine root cause of the high duration. This is not an uncommon scenario and up until now there has been a lack of obvious telemetry surfaced to the customer that helps them (or Microsoft customer support) diagnose the root cause of this type of slow-running query.
If you are able to mess around with the system, I would suggest stopping the query, enabling async stats updates, and then trying again.
@ConcernedOfTunbridgeWells The goal here is for a variety of clinical analysis, the data is all detailed structured clinical data about various cardiovascular studies.
Yeah, there are like 200 tables of data attached to the root study data, some of it nested, so a study can have measurements of different valves at different times during a cath. It's highly structured. Which means it's difficult for customers to be able to do analytics. So the goal is to transform this data into some kind of data mart for easier use by the customers.
> This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
It'd the first time it occurred to me but shouldn't we suggest editing the existing question with enough detail to show why it's a different question instead of asking a new one
If the question already has answers, editing it might invalidate them. Although in principle I agree that clarifying the existing question should be attempted before posting a new one.
@PaulWhite - what do you suggest we do to with this question - nearly 10,000 views over 4 years, but far to broad (probably) for the site. It's currently closed, so obviously no new answers can be added. Just re-open it?
I am looking to convert my SQL Server 2014 Express Database to Azure SQL Database.
My SQL Server database was automatically converted from Oracle a number of years ago, and needs the sysdb database as a dependency to provide user defined functions that emulate Oracle functions.
I ran the Data M...
