Zakładając, że masz na myśli, że obie maszyny łączyły się z tym samym serwerem, prawdopodobnie istniała różnica w ustawieniach, która spowodowała, że nieodpowiedni plan nie został udostępniony między dwoma połączeniami.
Aby połączenie mogło ponownie wykorzystać wcześniej zbuforowany plan, kilka ustawień (klucze pamięci podręcznej planu) musi być takich samych, w tym ANSI_NULLS , ARITHABORT , Language , DATEFIRST i domyślny schemat (jeśli zapytanie opiera się na niejawnym rozpoznawaniu nazw).
Możesz je zobaczyć, patrząc na sys.dm_exec_plan_attributes (te, w których is_cache_key=1 muszą być takie same między połączeniami).
Pełna lista atrybutów, w których is_cache_key=1 jest
dbid_execute
required_cursor_options
compat_level
parent_plan_handle
date_format
language_id
status
merge_action_type
is_replication_specific
objectid
acceptable_cursor_options
date_first
set_options
user_id
dbid
optional_spid
optional_clr_trigger_objid
optional_clr_trigger_dbid
set_options i cursor_options to flagi bitowe zawierające różne opcje jak udokumentowano tutaj
. W moim eksperymencie user_id faktycznie odnosi się do schema_id(default_schema_name) zamiast principal_id .
