I know what it does to dml-statements, but I'm not sure what it means for ddl.
Generally speaking, not much.
DDL encompasses a huge range of operations (many of which have their own special behaviours), but most DDL will take a schema modification (
Sch-M) lock on the underlying object, either for the duration of the command, or at a critical stage (e.g. at the end of most online index builds). This is the most restrictive type of lock, preventing any sort of concurrent access, at any isolation level.
Sch-M is not taken, the engine is careful to take the right locks at the appropriate times to ensure the end result is correct. For example, it is not possible to build an index that does not exactly reflect the underlying data.
All of the above applies regardless of any session isolation level specified by the user.
As far as changes to metadata (i.e. the system structures underlying views like
sys.tables) are concerned, while SQL Server ensures correct changes automatically, user access is only fully supported and guaranteed to be honoured at the default locking
READ COMMITTED isolation level.
Quoting from Metadata Access, Isolation Levels, and Lock Hints (emphasis added):
SQL Server does not guarantee that lock hints will be honored in queries that access metadata through catalog views, compatibility views, information schema views, metadata-emitting built-in functions.
Internally, the SQL Server Database Engine only honors the
READ COMMITTED isolation level for metadata access. If a transaction has an isolation level that is, for example,
SERIALIZABLE and within the transaction, an attempt is made to access metadata by using catalog views or metadata-emitting built-in functions, those queries will run until they are completed as
READ COMMITTED. However, under snapshot isolation, access to metadata might fail because of concurrent DDL operations. This is because metadata is not versioned. Therefore, accessing the following under snapshot isolation might fail:
- Catalog views
- Compatibility views
- Information Schema Views
- Metadata-emitting built-in functions
sp_help group of stored procedures
- SQL Server Native Client catalog procedures
- Dynamic management views and functions
From the same page:
The following table provides a summary of metadata access under various isolation levels.
Despite not being guaranteed or supported, it can be important to access metadata (e.g. catalog views, DMVs) under
READ UNCOMMITTED isolation to avoid blocking issues. Most tools and diagnostic scripts make heavy use of
READ UNCOMMITTED isolation (often using the synonymous but misleadingly-named
NOLOCK hint). For an example, see Glenn Berry's Diagnostic Queries.
As an example of
READ UNCOMMITTED access not being honoured, see Metadata functions should follow same isolation semantics as metadata queries on Connect and Bad habits : Using (certain) metadata "helper" functions by Aaron Bertrand.
Accessing metadata at an isolation higher than read committed is not even honoured - the information will be read with
READ COMMITTED isolation semantics.
If I had to guess, I would say the comparison tool in the question sets isolation to
SERIALIZABLE to cover any DML in the generated script.