Jak przechwycić dane przekazane w SqlBulkCopy za pomocą Sql Profiler?

Question

Cały czas używam Sql Profiler do przechwytywania instrukcji SQL i ponownego uruchamiania problematycznych. Bardzo przydatne.

Jednak niektóre kod wykorzystuje API SqlBulkCopy i nie mam pojęcia, w jaki sposób, aby uchwycić te. Widzę tworzenie tabel tymczasowych, ale nic, co je zapełnia. Wygląda na to, że SqlBulkCopy omija Sql Profiler lub nie przechwytuję właściwych zdarzeń.

Każda pomoc jest doceniana.

Answer 1

Nie można przechwycić SqlBulkCopy w programie SQL Profiler, ponieważ SqlBulkCopy nie generuje w ogóle SQL podczas wstawiania danych do tabeli programu SQL Server. SqlBulkCopy działa podobnie do narzędzia bcp i ładuje dane bezpośrednio do systemu plików SQL Server. Jest nawet can ignore FKs and triggers podczas wstawiania wierszy!

Answer 2

Przechwytywanie informacji zdarzeń dla masowych operacji INSERT (BCP.EXE, SqlBulkCopy, i zakładam BULK INSERT i OPENROWSET(BULK...) jest możliwe, ale nie będzie mógł zobaczyć poszczególne wiersze i kolumny.

Operacje zbiorcze Wstaw pokazać się jako singiel (dobrze, po jednej partii, a wartość domyślna to zrobić wszystkie wiersze w jednej partii) oświadczenie DML z:

INSERT BULK <destination_table_name> (
     <column1_name> <column1_datatype> [ COLLATE <column1_collation> ], ... 
    ) [ WITH (<1 or more hints>) ] 

<hints> := KEEP_NULLS, TABLOCK, ORDER(...), ROWS_PER_BATCH=, etc 

można znaleźć pełną listę "podpowiedzi" na stronie MSDN dla BCP Utility. Należy pamiętać, że SqlBulkCopy obsługuje tylko podzbiór tych wskazówek (np , TABLOCK i kilku innych), ale robi nie wsparcie ORDER(...) lub ROWS_PER_BATCH=^** (co jest dość niefortunne, rzeczywiście, jako wskazówkę ORDER() jest potrzebny aby uniknąć sortowania, które ma miejsce w tempdb, aby umożliwić minimalną rejestrację operacji (zakładając spełnienie innych warunków dla tej operacji)

Aby zobaczyć to stwierdzenie, musisz uchwycić każdą operację z następujących zdarzeń w SQL Server Profiler:

SQL: BatchStarting
SQL: BatchCompleted
SQL: StmtStarting
SQL: StmtCompleted

Będziesz także chcą, aby wybrać, co najmniej, następujące kolumny (SQL Server Profiler):

TextData
CPU
Odsłon
Zapisuje
Czas trwania
SPID
startTime
EndTime
RowCounts

A ponieważ użytkownik nie może złożyć oświadczenie INSERT BULK bezpośrednio, prawdopodobnie można filtrować że w filtrze kolumny jeśli tylko chcą zobaczyć te wydarzenia i nic więcej.

Jeśli chcesz zobaczyć oficjalne zawiadomienie, że operacja BULK INSERT jest początkiem i/lub końcowy, a następnie trzeba zarejestrować następujące zdarzenie:

SqlTransaction

a następnie dodać następujące kolumny Profiler:

EventSubClass
ObjectName

Dla ObjectName zawsze możesz liczyć wydarzenia wykazujące „BULK INSERT” i czy zaczyna się lub kończącym jest określana przez wartość w EventSubClass, który jest albo „0 - Rozpocznij” lub „1 - Commit” (i ja załóżmy, że jeśli się nie powiedzie, powinieneś zobaczyć "2 - Cofanie").

Jeśli wskazówka ORDER() nie został określony (i znowu, to niemoże być określona przy użyciu SqlBulkCopy), a następnie będzie można również uzyskać „SqlTransaction” wydarzenie pokazujące „sort_init” w kolumnie ObjectName. To zdarzenie ma również zdarzenia "0 - Rozpocznij" i "1 - Zatwierdź" (jak pokazano w kolumnie EventSubClass).

Wreszcie, choć nie widać konkretnych wierszy, nadal można zobaczyć operacje przeciwko dziennik transakcji (np wkładka rząd, modyfikować IAM wiersz, modyfikować PFS wiersz, etc), jeśli uchwycić następujące zdarzenie:

TransactionLog

i dodać po kolumnie Profiler:

ObjectID

Główne interesujące informacje będą w kolumnie EventSubClass, ale niestety są to tylko wartości ID i nie mogłem znaleźć żadnego tłumaczenia tych wartości w dokumentacji MSDN. Jednak znalazłem następujący wpis na blogu Jonathana Kehayiasa: Using Extended Events in SQL Server Denali CTP1 to Map out the TransactionLog SQL Trace Event EventSubClass Values.

@RBarryYoung podkreślić, że wartości EventSubClass i nazwy można znaleźć w widoku sys.trace_subclass_values katalogowej, ale odpytywanie ten pogląd pokazuje, że nie ma wierszy dla przypadku TransactionLog:

SELECT * FROM sys.trace_categories -- 12 = Transactions 
SELECT * FROM sys.trace_events WHERE category_id = 12 -- 54 = TransactionLog 
SELECT * FROM sys.trace_subclass_values WHERE trace_event_id = 54 -- nothing :(

---

^** Należy pamiętać, że właściwość SqlBulkCopy.BatchSize jest równoważna ustawieniu opcji dla BCP.EXE, która jest ustawieniem operacyjnym określającym sposób podziału wierszy przez każde polecenie w zestawy. To nie jest to samo, co podpowiedź ROWS_PER_BATCH=, która nie kontroluje fizycznie sposobu podziału wierszy na zestawy, ale zamiast tego pozwala programowi SQL Server lepiej planować sposób alokowania stron, a tym samym zmniejsza liczbę wpisów w dzienniku transakcji (czasami całkiem sporo). Nadal mój badania wykazały, że:

• podając -b dla BCP.EXE ustawił podpowiedź ROWS_PER_BATCH= na tę samą wartość.
• określając właściwość SqlBulkCopy.BatchSize podała nie ustawić podpowiedź ROWS_PER_BATCH=, ale korzyści z obniżonej aktywności dziennika transakcji było jakoś tam zdecydowanie (magia?). Fakt, że efekt netto ma nadal przynosić korzyści, to dlatego, że nie wspomniałem o tym na wierzchu, gdy powiedziałem, że to niefortunne, że podpowiedź ORDER() nie była obsługiwana przez SqlBulkCopy.