Come fare un backup di un Server Core Windows 2008 R2 senza usare strumenti di terze parti, ma sfruttando il backup integrato di Windows?
1) Installiamo la funzionalità di backup:
start /w ocsetup WindowsServerBackup
2) Eseguiamo il backup da riga di comando:
wbadmin start backup -allCritical -backupTarget:"\\Nome_Server\Backup_Folder"
Per approfondimenti sul comando WBADMIN
martedì 31 gennaio 2012
lunedì 23 gennaio 2012
SQL Server 2008 Data Collector
Versione in italiano
Introduction
The typical problems of any DBA is to monitor the installation of its DB in terms of performance and server loads.
The process of preparing data collectors in order to do an analysis usually is a time-consuming and tricky task.
But if we are Database SQL Server 2008 lucky DBA, Microsoft has developed a tool that does the work for us: SQL data collector (not to be confused with Windows performace monitor Data Collector).
In this way, the data collectors become a powerful ally of all DBAs, especially those less experienced.
Architecture
Although the architecture is quite complex
Installation is very simple because the configuration and parameterization is minimal, however, the data collector was designed to have extremely low overhead on the system when collecting and analyzing data.
It creates SSIS Package (SQL Server Integration Service) launched by SQL Server Agent Jobs working to collect and store data in a Management Data WareHouse (from henceforth MDW ) and finally the information is shown through a series of dynamic reports linked to each other that allow us to analyze in detail our SQL Server instances activities and trends.
Installation
Open SSMS and go to the section of Management, right-click and select a data collector configuration data collectors
Then proceed with the MDW configuration
Going forward we are asked to configure roles and permissions, but if you don't have any special need you can proceed without selecting anything. So you complete this first configuration phase
Again we return to the Configuration
And this time we choose to set the data collection
and simply select the previous data warehouse and choose a directory in which park the data collected before they are placed in the MDW (see below: Query and System collectors collect data with a high frequency, but uploading to the Data Wharehouse is deferred in ways to avoid too much overhead due a nearly continuous data entry)
Even here we can proceed and complete the configuration
At this time our collectors are finally activated and slowly begin to populate our MDW
Data Collectors
After configuring our SSIS packages and their jobs are ready and running, you'll see the collectors properties below that are shown only for explanatory purposes, those who were not interested in learning more can safely skip this paragraph.
How we can inferred in the previous images we have three types of collectors (4 in SQL 2008 R2):
Sampling is done every 6 hours and is loaded simultaneously on the MDW (given the low frequency). The data is kept for 730 days so as to allow adequate delineation of the growth trends.
Query statistics: collects data on SQL statements and their execution plans sampling every 10 seconds some Dynamic Management Views ( from now DMV). MDW loading in this case is delayed and occurs every 15 minutes. Collected data is stored in the MDW for 14 days.
Server Activity: provides a view on the SQL Server activity, resources use and competition over resources, and also collects data on overall System resources allowing to identify any bottlenecks external respect than DB engine. In this case the data are collected by querying DMVs and SQL Sever and system performance counters.
Sampling occurs every 60 seconds and the data is uploaded every 15 minutes in the MDW where they are kept for 14 days.
As can be seen from the images is possible, but absolutely not necessary, change any parameter, such as data retention period in the MDW.
Reports
If you do not want to wait for the default schedules at any time you can force data collection and loading .
Collected data analysis will put a strain on even a very experienced DBA, and for this reason that the second, and perhaps the greatest, advantage of the Data Collector are available reports.
As you can see reports are related one to one with collectors.
So let's see how our data are available and their graphical representation.
I apologize for the fact that all pictures are taken from a test environment virtually stationary, where the only load is the Data Collector, but this must not lead to the error of thinking that the tool creates a strong overhead on monitored systems.
Disk Usage
Show all of our instance databases data and log files in terms of size and growth. Clicking on the name of the individual DB we can see free space and a list of all events related to their growth.
Query Statistics
First displays Queries Top 10 in relation to their resource consumption (default CPU) in a graphical format
and in textual form
Clicking on a single statement you can display details with valuable informations about resources use and the possibility of going into Waits details.
Server Activity:
Conclusions and final notes
As we have seen this tool combines two great qualities: ease of configuration and power of analisys, so I'm sure that it will soon become part of almost all of your SQL Server installations.
Unfortunately, SQL Server 2005 does not support data collectors but MSSQLDUDE suggests us a technique to remedy the problem (to be honest I have never tried it)
Also remember that you can always export charts to PDF or Excel format.
Link:
Data Collector on MSDN
SQL Authority (where I stole some pictures)
Introduction
The typical problems of any DBA is to monitor the installation of its DB in terms of performance and server loads.
The process of preparing data collectors in order to do an analysis usually is a time-consuming and tricky task.
But if we are Database SQL Server 2008 lucky DBA, Microsoft has developed a tool that does the work for us: SQL data collector (not to be confused with Windows performace monitor Data Collector).
In this way, the data collectors become a powerful ally of all DBAs, especially those less experienced.
Architecture
Although the architecture is quite complex
 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Data Collector Architecture: source MSDN |
It creates SSIS Package (SQL Server Integration Service) launched by SQL Server Agent Jobs working to collect and store data in a Management Data WareHouse (from henceforth MDW ) and finally the information is shown through a series of dynamic reports linked to each other that allow us to analyze in detail our SQL Server instances activities and trends.
Installation
Open SSMS and go to the section of Management, right-click and select a data collector configuration data collectors
Then proceed with the MDW configuration
Choose where you want to create it and how to call it (I've imaginatively called it DataCollector).
CAUTION: The data warehouse DB can come to occupy up to 10GB of disk space!
So be careful where you position it and its initial and maximum size (if you want to set it)
Going forward we are asked to configure roles and permissions, but if you don't have any special need you can proceed without selecting anything. So you complete this first configuration phase
Again we return to the Configuration
And this time we choose to set the data collection
and simply select the previous data warehouse and choose a directory in which park the data collected before they are placed in the MDW (see below: Query and System collectors collect data with a high frequency, but uploading to the Data Wharehouse is deferred in ways to avoid too much overhead due a nearly continuous data entry)
Even here we can proceed and complete the configuration
At this time our collectors are finally activated and slowly begin to populate our MDW
Data Collectors
After configuring our SSIS packages and their jobs are ready and running, you'll see the collectors properties below that are shown only for explanatory purposes, those who were not interested in learning more can safely skip this paragraph.
How we can inferred in the previous images we have three types of collectors (4 in SQL 2008 R2):
- Disk Usage
- Query Statistics
- Server Activity
Sampling is done every 6 hours and is loaded simultaneously on the MDW (given the low frequency). The data is kept for 730 days so as to allow adequate delineation of the growth trends.
Query statistics: collects data on SQL statements and their execution plans sampling every 10 seconds some Dynamic Management Views ( from now DMV). MDW loading in this case is delayed and occurs every 15 minutes. Collected data is stored in the MDW for 14 days.
Server Activity: provides a view on the SQL Server activity, resources use and competition over resources, and also collects data on overall System resources allowing to identify any bottlenecks external respect than DB engine. In this case the data are collected by querying DMVs and SQL Sever and system performance counters.
Sampling occurs every 60 seconds and the data is uploaded every 15 minutes in the MDW where they are kept for 14 days.
As can be seen from the images is possible, but absolutely not necessary, change any parameter, such as data retention period in the MDW.
Reports
If you do not want to wait for the default schedules at any time you can force data collection and loading .
Collected data analysis will put a strain on even a very experienced DBA, and for this reason that the second, and perhaps the greatest, advantage of the Data Collector are available reports.
As you can see reports are related one to one with collectors.
So let's see how our data are available and their graphical representation.
I apologize for the fact that all pictures are taken from a test environment virtually stationary, where the only load is the Data Collector, but this must not lead to the error of thinking that the tool creates a strong overhead on monitored systems.
Disk Usage
Show all of our instance databases data and log files in terms of size and growth. Clicking on the name of the individual DB we can see free space and a list of all events related to their growth.
First displays Queries Top 10 in relation to their resource consumption (default CPU) in a graphical format
and in textual form
This report displays the graphs for the four SQL tuning key resources. Very interesting is the fact that allows us to separate SQL Server from System activity.
It also puts in a graphical format, with the ability to go into detail with a single click, SQL Server Waits and the most significant activities in terms of SQL Server monitoring.
It also puts in a graphical format, with the ability to go into detail with a single click, SQL Server Waits and the most significant activities in terms of SQL Server monitoring.
Conclusions and final notes
As we have seen this tool combines two great qualities: ease of configuration and power of analisys, so I'm sure that it will soon become part of almost all of your SQL Server installations.
Unfortunately, SQL Server 2005 does not support data collectors but MSSQLDUDE suggests us a technique to remedy the problem (to be honest I have never tried it)
Also remember that you can always export charts to PDF or Excel format.
Link:
Data Collector on MSDN
SQL Authority (where I stole some pictures)
domenica 22 gennaio 2012
Il Data Collector di SQL Server 2008
English Version
Introduzione
Il tipico problema di ogni DBA è tenere sotto controllo le installazioni dei propri DB in termini di performance e carichi del server.
Il processo di preparazione di collettori di dati per poter fare analisi è normalmente un task laborioso e spinoso.
Ma se siamo dei fortunati DBA di Database SQL Server 2008, Microsoft ha predisposto uno strumento che fa il lavoro al nostro posto: i data collector per SQL (da non confondere con gli omonimi del performace monitor di Windows).
In questo modo i data collector diventano un potentissimo alleato di tutti i DBA, soprattutto di quelli meno esperti.
Architettura
Nonostante l'architettura sia abbastanza complessa
l'installazione risulta essere molto semplice in quanto la configurazione e la parametrizzazione è minima, peraltro il data collector è stato disegnato per avere un overhead molto basso sul sistema in fase di raccolta ed analisi dei dati.
Crea dei pacchetti SSIS (SQL Server Integration Service), lanciati tramite dei JOB e quindi l'Agent di SQL Server, che si occupano di raccogliere e memorizzare i dati all'interno di un Data Ware House di gestione (Managemet Data WhareHouse da ora in poi MDW) ; infine rappresenta le informazioni raccolte tramite una serie di Report dinamici linkati tra di loro che ci consentono di analizzare a fondo l'attività ed i trend delle nostre istanze di SQL Server.
Installazione
Apriamo SSMS ed andiamo nella sezione di Gestione, tasto destro su data collector e selzioniamo configura data collector
poi procediamo con la configurazione del MDW:
Andando avanti ci viene chiesto di configurare i ruoli e le autorizzazioni, ma se non avete esigenze particolari potete semplicemnte procedere senza selezionare nulla andando completare la prima fase di configurazione
Nuovamente torniamo sulla configurazione
E questa volta scegliamo di impostare la collezione dei dati
e semplicemente selezioniamo il Data Wharehouse creato precendentemente ed una directory in cui parcheggiare i dati raccolti prima che vengano inseriti nel MDW (come vedremo più avanti i collettori delle query e di sistema raccolgono dati con un'elevata frequenza, ma il caricamento nel DB di Data Wharehouse avviene in maniere differita per evitare un eccessivo overhead dovuto ad un quasi continuo inserimento di dati)
Anche qui possiamo procedere e completare la configurazione
A questo i nostri collettori sono finalmente attivati e pian piano il nostro MDW comincerà a popolarsi
I Data Collector
Finita la configurazione i nostri pacchetti SSIS ed i loro Job sono pronti e funzionanti; le proprietà dei collettori che vedrete di seguito sono visualizzate solo a scopo esplicativo, chi non fosse interessato ad approfondire può tranquillamente saltare questo paragrafo.
Come possiamo evincere nell'immagine precedente abbiamo tre tipologie di collettori (4 su SQL 2008 R2):
Il campionamento avviene ogni 6 ore e viene simultaneamente caricato sul MDW (vista la bassa frequenza). I dati vengono mantenuti per 730 giorni in maniera da consentire un adeguato delineamento dei trend di crescita.
Statistiche sulle Query: raccoglie dati sugli statement SQL ed i relativi piani di esecuzione campionando alla frequenza di 10 secondi alcune viste di gestione dinamica ( Dynamic Management Views, da ora in poi DMV). Il caricamento in questo caso è differito ed avviene ogni 15 minuti. I dati vengono conservati nel MDW per 14 giorni.
Attività del Server: fornisce una visualizzazione sull'attività, l'utilizzo di risorse e la competizione sulle risorse di SQL Server, raccoglie inoltre dati generali sulle risorse di sistema per consetire l'identificazione di eventuali colli di bottiglia esterni rispetto al motore di DB. In questo caso i dati vengono raccolti sia dalle DMV che da molti contatori di performance di SQL Sever e di sistema.
Il campionamento avviene ogni 60 secondi ed i dati vengono caricati sul MDW ogni 15 minuti dove vengono conservati per 14 giorni.
Come si evince dalle immagini è possibile, ma assolutamente non necessario, modificare alcuni parametri, come ad esempio il periodo di di ritenzione dei dati nel MDW.
I Report
Se non avete voglia di aspettare le schedulazioni predefinite potete in qualsiasi momento forzare la raccolta ed il caricamento dei dati.
L'analisi dei dati raccolti mettere a dura prova anche un DBA di grande esperienza, e per questo motivo che il secondo, e forse anche il più grande, vantaggio del Data Collector sono i report che mette a disposizione.
Come vedete i report sono in rapporto uno ad uno con i collettori.
Vediamo quindi i dati che ci vengono messi a disposizione e la loro rappresentazione grafica.
Mi scuso per il fatto che tutte le immagini sono prese da un ambiente di test praticamente fermo, in cui l'unico carico è quello del Data Collector, ma questo non deve assolutamente indurre nell'errore di pensare che lo strumento crei un forte overhead sul sistema monitorato.
Utilizzo del disco
Visualizza tutti i file di Dati e Log dei Database della nostra istanza in termini di grandezza e crescita. Cliccando sul nome del singolo DB possiamo vedere lo spazio libero e l'elenco di tutti gli eventi correlati alla loro crescita.
Statistiche sulle Query
Innanzitutto visualizza la TOP 10 delle Query relativamente al consumo di risorse (di default la CPU) in formato grafico
ed in forma testuale
Cliccando poi sul singolo statement si entra in una visualizzazione di dettaglio con preziosissime informazioni inerenti le risorse utilizzate e la possbilità di entrare nel dettaglio dei waits
Attività del Server:
Conclusioni e note finali
Come abbiamo visto questo strumento coniuga due grandi qualità: semplicità di configurazione e potenza di analisi, quindi sono certo che diventerà presto parte di quasi tutte le vostre installazioni di SQL Server.
Purtroppo SQL Server 2005 non supporta i data collector ma MSSQLDUDE suggerisce una tecnica per ovviare al problema (ad onor del vero non l'ho mai provata).
Inoltre ricordate che potete sempre esportare i grafici in formato PDF o Excel.
Link:
Data Collector su MSDN
SQL Authority (a cui ho rubato un pò di immagini)
Introduzione
Il tipico problema di ogni DBA è tenere sotto controllo le installazioni dei propri DB in termini di performance e carichi del server.
Il processo di preparazione di collettori di dati per poter fare analisi è normalmente un task laborioso e spinoso.
Ma se siamo dei fortunati DBA di Database SQL Server 2008, Microsoft ha predisposto uno strumento che fa il lavoro al nostro posto: i data collector per SQL (da non confondere con gli omonimi del performace monitor di Windows).
In questo modo i data collector diventano un potentissimo alleato di tutti i DBA, soprattutto di quelli meno esperti.
Architettura
Nonostante l'architettura sia abbastanza complessa
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Architettura dei DATA Collector: fonte MSDN |
Crea dei pacchetti SSIS (SQL Server Integration Service), lanciati tramite dei JOB e quindi l'Agent di SQL Server, che si occupano di raccogliere e memorizzare i dati all'interno di un Data Ware House di gestione (Managemet Data WhareHouse da ora in poi MDW) ; infine rappresenta le informazioni raccolte tramite una serie di Report dinamici linkati tra di loro che ci consentono di analizzare a fondo l'attività ed i trend delle nostre istanze di SQL Server.
Installazione
Apriamo SSMS ed andiamo nella sezione di Gestione, tasto destro su data collector e selzioniamo configura data collector
poi procediamo con la configurazione del MDW:
Scegliamo dove crearlo e come chiamarlo (io con molta fantasia l'ho chiamato DataCollector).
ATTENZIONE: a regime il Data WhareHouse può arrivare ad occupare fino a 10GB di spazio disco!
Quindi fate attenzione a dove lo posizionate ed alle dimensioni iniziali, incrementiali e massime (se proprio dovete impostarle)
Andando avanti ci viene chiesto di configurare i ruoli e le autorizzazioni, ma se non avete esigenze particolari potete semplicemnte procedere senza selezionare nulla andando completare la prima fase di configurazione
Nuovamente torniamo sulla configurazione
E questa volta scegliamo di impostare la collezione dei dati
e semplicemente selezioniamo il Data Wharehouse creato precendentemente ed una directory in cui parcheggiare i dati raccolti prima che vengano inseriti nel MDW (come vedremo più avanti i collettori delle query e di sistema raccolgono dati con un'elevata frequenza, ma il caricamento nel DB di Data Wharehouse avviene in maniere differita per evitare un eccessivo overhead dovuto ad un quasi continuo inserimento di dati)
Anche qui possiamo procedere e completare la configurazione
A questo i nostri collettori sono finalmente attivati e pian piano il nostro MDW comincerà a popolarsi
I Data Collector
Finita la configurazione i nostri pacchetti SSIS ed i loro Job sono pronti e funzionanti; le proprietà dei collettori che vedrete di seguito sono visualizzate solo a scopo esplicativo, chi non fosse interessato ad approfondire può tranquillamente saltare questo paragrafo.
Come possiamo evincere nell'immagine precedente abbiamo tre tipologie di collettori (4 su SQL 2008 R2):
- Utilizzo del disco
- Statistiche sulle Query
- Attività del Server
Il campionamento avviene ogni 6 ore e viene simultaneamente caricato sul MDW (vista la bassa frequenza). I dati vengono mantenuti per 730 giorni in maniera da consentire un adeguato delineamento dei trend di crescita.
Statistiche sulle Query: raccoglie dati sugli statement SQL ed i relativi piani di esecuzione campionando alla frequenza di 10 secondi alcune viste di gestione dinamica ( Dynamic Management Views, da ora in poi DMV). Il caricamento in questo caso è differito ed avviene ogni 15 minuti. I dati vengono conservati nel MDW per 14 giorni.
Attività del Server: fornisce una visualizzazione sull'attività, l'utilizzo di risorse e la competizione sulle risorse di SQL Server, raccoglie inoltre dati generali sulle risorse di sistema per consetire l'identificazione di eventuali colli di bottiglia esterni rispetto al motore di DB. In questo caso i dati vengono raccolti sia dalle DMV che da molti contatori di performance di SQL Sever e di sistema.
Il campionamento avviene ogni 60 secondi ed i dati vengono caricati sul MDW ogni 15 minuti dove vengono conservati per 14 giorni.
Come si evince dalle immagini è possibile, ma assolutamente non necessario, modificare alcuni parametri, come ad esempio il periodo di di ritenzione dei dati nel MDW.
I Report
Se non avete voglia di aspettare le schedulazioni predefinite potete in qualsiasi momento forzare la raccolta ed il caricamento dei dati.
L'analisi dei dati raccolti mettere a dura prova anche un DBA di grande esperienza, e per questo motivo che il secondo, e forse anche il più grande, vantaggio del Data Collector sono i report che mette a disposizione.
Come vedete i report sono in rapporto uno ad uno con i collettori.
Vediamo quindi i dati che ci vengono messi a disposizione e la loro rappresentazione grafica.
Mi scuso per il fatto che tutte le immagini sono prese da un ambiente di test praticamente fermo, in cui l'unico carico è quello del Data Collector, ma questo non deve assolutamente indurre nell'errore di pensare che lo strumento crei un forte overhead sul sistema monitorato.
Utilizzo del disco
Visualizza tutti i file di Dati e Log dei Database della nostra istanza in termini di grandezza e crescita. Cliccando sul nome del singolo DB possiamo vedere lo spazio libero e l'elenco di tutti gli eventi correlati alla loro crescita.
Innanzitutto visualizza la TOP 10 delle Query relativamente al consumo di risorse (di default la CPU) in formato grafico
ed in forma testuale
Cliccando poi sul singolo statement si entra in una visualizzazione di dettaglio con preziosissime informazioni inerenti le risorse utilizzate e la possbilità di entrare nel dettaglio dei waits
questo report consente di visualizzare dei grafici relativi alle quattro risorse fondamentali in fase di tuning di SQL. Molto interessante è il fatto che ci consente di separare l'attività SQL Server da quella di Sistema.
Inoltre mette in formato grafico, con la possibilità di entrare nel dettaglio tramite un semplice click sia i Wait che le attività più significative in termini di performance tuning del server SQL.
Conclusioni e note finali
Come abbiamo visto questo strumento coniuga due grandi qualità: semplicità di configurazione e potenza di analisi, quindi sono certo che diventerà presto parte di quasi tutte le vostre installazioni di SQL Server.
Purtroppo SQL Server 2005 non supporta i data collector ma MSSQLDUDE suggerisce una tecnica per ovviare al problema (ad onor del vero non l'ho mai provata).
Inoltre ricordate che potete sempre esportare i grafici in formato PDF o Excel.
Link:
Data Collector su MSDN
SQL Authority (a cui ho rubato un pò di immagini)
martedì 17 gennaio 2012
Trucco: CmdKey
Le connessioni verso un client o server che richiedono autenticazione hanno necessità di creare un contesto di autorizzazione.
Tipicamente ci viene richiesto di inserire Utente e Password, le credenziali immesse vengono memorizzate sul computer locale e riutilizzate automaticamente quando ci si connette nuovamente al compuer remoto.
Come gestire questo archivio?
Tramite l'utility a riga di comando cmdkey.exe.
Esempi:
cmdkey /list -- fa una lista delle credenziali memorizzate
cmdkey /add:server01 /user:mikedan -- usa l'utente mikedan per connetersi al server01
cmdkey /delete:server01 -- elimina le credenziali per connettersi al server01
http://technet.microsoft.com/en-us/library/cc754243(WS.10).aspx
Tipicamente ci viene richiesto di inserire Utente e Password, le credenziali immesse vengono memorizzate sul computer locale e riutilizzate automaticamente quando ci si connette nuovamente al compuer remoto.
Come gestire questo archivio?
Tramite l'utility a riga di comando cmdkey.exe.
Esempi:
cmdkey /list -- fa una lista delle credenziali memorizzate
cmdkey /add:server01 /user:mikedan -- usa l'utente mikedan per connetersi al server01
cmdkey /delete:server01 -- elimina le credenziali per connettersi al server01
http://technet.microsoft.com/en-us/library/cc754243(WS.10).aspx
Iscriviti a:
Post (Atom)