Care sistem de memorie va fi folosit de pachetul ssis?

Am câteva întrebări despre utilizarea memoriei în pachetul ssis.

  1. Dacă se încarcă date de la serverul A la serverul B și pachetul ssis se află în sistemul meu desktop și se execută prin BIDS, dacă crearea tamponului (utilizarea memoriei) se va întâmpla în sistemul desktop? caz, performanța (comparație slabă cu serverele) va fi lentă?

  2. Cum să activezi utilizarea resurselor serverului în timp ce dezvolți pachetul în sistemul desktop?

  3. Te rog ajută-mă, dacă am 3 dezvoltatori ssis și toate sunt în curs de dezvoltare diferite pachete la un moment dat, Care este cea mai bună metodă de dezvoltare?

0

3 răspunsuri

Extinderea răspunsurilor lui Diego și Bill:

1) Diego are acest lucru cel mai corect, aș adăuga: Pachetul rulează pe computerul care îl rulează, dar chiar și mai rău, executarea unui pachet prin BIDS nu este chiar aproape de ceea ce veți vedea pe un server de la procesul pe care BIDS îl folosește rulați pachetul este un proces pe 32 de biți care rulează local. Veți fi mai lent din cauza limitelor legate de rularea în subsistemul de 32 de biți, precum și de copierea tuturor datelor dvs. pentru tampon în întreaga rețea la memoria tampon din memoria stației dvs. de lucru, transformându-o în fluxul pachetului dvs. și apăsându-l din nou prin intermediul rețelei către serverul de destinație. Acest lucru este bine pentru testarea subseturilor mici de date într-un mediu de testare, dar nu ar trebui să fie utilizat pentru a estima performanța unui sistem de servere.

2) Diego are acest drept. Dacă doriți să vedeți performanța serverului, implementați-l pe un server de testare și executați-l acolo.

3) Billinkc are acest lucru corect. Unul dintre marile dezavantaje ale SSIS în TFS este că nu există o modalitate elegantă de a împărtăși munca unui singur pachet. Dacă doriți să utilizați mai mult de un dezvoltator într-un singur proces, rupeți-l în bucăți mai mici și permiteți unui singur dezvoltator să lucreze la fiecare piesă. Atâta timp cât nu dezvoltă același pachet în același timp, ar trebui să fii bine.

0
adăugat
mulțumesc pentru toate confirmările, +1 pentru că ai adăugat informații bune despre elementul 1
adăugat autor Diego, sursa
Și 32 de biți sau nu, care rulează în cadrul BIDS/SSDT împachetează procesul cu debuggerul continuând să-l încetinească. Un test mai precis (memorie, trecere, etc) ar fi să invocați pachetul din linia de comandă (dtexec/file C: \ path \ to \ myPackage.dtsx)
adăugat autor billinkc, sursa
  1. Da. Un pachet rulează pe același computer ca programul care îl lansează. Chiar și atunci când un program încarcă un pachet stocat de la distanță pe un alt server, pachetul rulează pe computerul local.

  2. Dacă prin resursele de server înțelegeți serverul de procesor, nu puteți cânta. Este ca și cum ați folosi resursele unui alt computer din rețea. Desigur, dacă aveți o OleDBSource care rulează un server select pe serverul SQL, CPU-ul care "rulează" selecția va fi cel de pe SQL Server, evident, dar odată ce setul de rezultate este preluat, acesta este gestionat de computerul în care pachetul se execută.

  3. Ca orice altă metodă de dezvoltare. Dacă aveți o clasă pe un proiect C# dezvoltat de 3 dezvoltatori, cum faceți acest lucru? Puteți avea fiecare dezvoltator să lucreze la același fișier și să îmbine schimbările, după toate acestea un pachet este un fișier xml, dar este mult mai complicat. Nu aș recomanda. Am fost în situații în care mai mulți dezvoltatori au lucrat pe același pachet, dar nu în același timp.

0
adăugat

Pentru a extinde numărul 3, cea mai bună metodă pe care am găsit-o pentru a permite echipelor să lucreze la o singură soluție SSIS este de a descompune o problemă (pachet) în bucăți mai mici și mai mici și de a controla invocarea lor printr-un tip parent-child/master-slave relaţie.

De exemplu, soluția se referă la încărcarea depozitului de date. Aș putea avea 2 pachete de controler, FactController.dtsx și DimensionController.dtsx. Responsabilitatea lor este să apeleze diferitele pachete care rezolvă nevoia (încărcarea faptelor sau a dimensiunilor). Poate că pachetul meu DimensionProductLoader se ocupă de o fulg de zăpadă (trebuie să actualizeze produsul și tabelul SubProduct), astfel încât devine descompus în 2 pachete.

Scopul acestui lucru este de a rupe procesul de dezvoltare în bucăți ușor de gestionat pentru a evita accesul simultan la un singur pachet. Îmbinarea cu xml nu va fi o utilizare productivă a timpului tău.

Singura resursă partajată pentru toate acestea este fișierul proiectului SSIS (dtproj), care este doar un document xml care enumeră pachetele care compromit proiectul. Creați un proiect schelet în avans, cu pachete binecunoscute, goale și puteți săriți probabil o parte din durerea inițială din jurul oamenilor încercând să îmbinați proiectul înapoi în depozit. Mi se pare că tipul de fuziune unic merge mult mai bine, cel puțin pentru TFS, decât dacă toți verifică globurile xml din nou.

0
adăugat
o idee foarte buna.
adăugat autor Diego, sursa