Looking at your query execution plan it doesn't look like you database contains any indexes or they where disabled during/by the migration process.
Based on the statement in your question:
With this join, I create an index on the F_Skonto table with the three columns gueltig_ab, gueltig_bis and CD_Kunde. Is that correct?
...I'm not sure if you are aware of what an index is. The answer to your question is:
No, a JOIN does not create an index. A JOIN can cause an existing index to be used to speed up the query.
Your statement may have been based on your knowledge of the English language and thus be misleading. I'll asume you know that an index is basically a Table of Contents that the the SQL Server Database Engine can use to speed up queries by knowing where to look for the data.
In that case we may be looking at the possible issue that the indexes are all disabled. If an index is disable it can't be use for speeding up queries.
Execute the following query to see if you have indexes which have been disalbed:
SELECT s.name AS Schema_name,
o.name AS Table_Name,
i.name AS Index_Name,
i.is_disabled AS Index_Disabled
FROM sys.objects AS o
JOIN sys.schemas AS s
ON s.schema_id = o.schema_id
JOIN sys.indexes AS i
ON i.object_id = o.object_id
JOIN sys.sysindexes as si
ON si.[id] = i.object_id
AND si.indid = i.index_id
WHERE 1=1
AND s.name != 'sys' -- Exclude sys items
AND i.is_disabled = 1 -- Show only disabled indexes
ORDER BY
1,2,3
This will produce a similar output to this:
+----------------+------------+--------------------+----------------+
| Schema_name | Table_Name | Index_Name | Index_Disabled |
+----------------+------------+--------------------+----------------+
| HumanResources | Department | AK_Department_Name | 1 |
+----------------+------------+--------------------+----------------+
If any indexes have been disabled in your tables, then you will receive a list. With this list you can then go ahead and rebuild the indexes which will enable them again and which might result in a faster SELECT part of your INSERT statement.
If no disabled indexes are returned by the above statement, then we will check if you have any indexes at all by running the same statement without the AND i.is_disabled = 1 part.
Like this:
SELECT s.name AS Schema_name,
o.name AS Table_Name,
i.name AS Index_Name,
i.is_disabled AS Index_Disabled
FROM sys.objects AS o
JOIN sys.schemas AS s
ON s.schema_id = o.schema_id
JOIN sys.indexes AS i
ON i.object_id = o.object_id
JOIN sys.sysindexes as si
ON si.[id] = i.object_id
AND si.indid = i.index_id
WHERE 1=1
AND s.name != 'sys' -- Exclude sys items
ORDER BY
1,2,3
In my AdventureWorks2012 database provided by Microsoft, this will produce a list which looks like this:
+----------------+--------------------------+------------------------------------------------+----------------+
| Schema_name | Table_Name | Index_Name | Index_Disabled |
+----------------+--------------------------+------------------------------------------------+----------------+
| dbo | AWBuildVersion | PK_AWBuildVersion_SystemInformationID | 0 |
| dbo | DatabaseLog | NULL | 0 |
| dbo | DatabaseLog | PK_DatabaseLog_DatabaseLogID | 0 |
| dbo | ErrorLog | PK_ErrorLog_ErrorLogID | 0 |
| dbo | ufnGetContactInformation | NULL | 0 |
| HumanResources | Department | AK_Department_Name | 1 |
| HumanResources | Department | PK_Department_DepartmentID | 0 |
| HumanResources | Employee | AK_Employee_LoginID | 0 |
| HumanResources | Employee | AK_Employee_NationalIDNumber | 0 |
| HumanResources | Employee | AK_Employee_rowguid | 0 |
| HumanResources | Employee | IX_Employee_OrganizationLevel_OrganizationNode | 0 |
| HumanResources | Employee | IX_Employee_OrganizationNode | 0 |
| HumanResources | Employee | PK_Employee_BusinessEntityID | 0 |
If the above statement does not provide any output, then your tables don't have any indexes. We will have to start creating some...
