Dataprix

A seguito della richiesta: “al fine di poter disegnare report (RDLC) basati su liste personalizzate di SharePoint; è possibile definire come datasource una lista di SharePoint o un Web Service ?“

Le risposte sono contenute nel link seguente:

Reporting Services: Using XML and Web Service Data Sources:
http://msdn.microsoft.com/en-us/library/aa964129.aspx

“New to Microsoft SQL Server 2005 Reporting Services (SSRS) is integrating Report Services directly with XML data sources and Web services. This white paper provides general information and tips for designing reports using these sources. It is intended to provide a starting point and overview of the available features, in addition to outlining many common scenarios. The intended audience is more experienced report authors who want to extend and integrate reporting with more services-oriented environments.”

E’ quindi possibile utilizzare SharePoint Lists.asmx come data source.

      

A seguito della richiesta “E’ possibile installare sullo stesso server Microsoft Office SharePoint Server 2007 e Microsoft Search Server 2008?” ho preparato della documentazione.
 
Non è possibile installare i due prodotti sullo stesso server in quanto Microsoft Office SharePoint Server 2007 comprende tutte le features presenti in Microsoft Search Server 2008 mentre è altresì possibile effettuare l’upgrade da Microsoft Search Server 2008 a Microsoft Office SharePoint Server 2007 così come descritto al seguente link:
 
Upgrade to Office SharePoint Server 2007 by installing each component separately:
http://technet.microsoft.com/en-us/library/cc671412.aspx#B4Ubegin
 
I link sottostanti illustrano come configurare Microsoft Office SharePoint Server 2007 per la ricerca documentale in modo da sostituire le funzionalità di Microsoft Search Server 2008
 
Configure the Office SharePoint Server Search service (Office SharePoint Server):
http://technet.microsoft.com/en-us/library/cc262700.aspx#section1
 
Configure business data search:
http://technet.microsoft.com/en-us/library/cc262659.aspx

      

A questo primo link si possono trovare informazioni generali
 
Panoramica di Microsoft System Center Configuration Manager 2007
 
a questo link si possono trovare utili informazioni sul Deployment dei sistemi operativi e sul Software Distribution
 
Deployment dei sistemi operativi
 
Microsoft System Center Configuration Manager 2007 per la distribuzione del software
 
a questo indirizzo si possono trovare i prerequisiti indispensabili per la distribuzione
 
Prerequisites for Software Distribution (Inglese)
 
segnalo inoltre un webcast e una presentazione che introducono alle funzionalità del prodotto
 
TechNet Virtual Lab: Introduction to System Center Configuration Manager (SCCM) 2007 (Inglese)
 
System Center Configuration Manager 2007: Overview (Inglese)
 
Infine, a questo indirizzo invece chi lo desidera potrà scaricare una versione trial del prodotto
 
System Center Configuration Manager Downloads

      

Per chi si trovasse nella necessità di integrare informazioni provenienti da Microsoft Dynamics CRM 3.0 all’interno dei siti SharePoint (WSS 3.0 o MOSS 2007), ecco una webpart che potrebbe tornare utile.
La webpart, gratuita e realizzata da Microsoft, fornisce una serie di funzionalità di collegamento agli elementi di MS CRM 3.0.
Ecco il link per il download.
http://www.microsoft.com/downloads/details.aspx?FamilyID=bc9b3526-decf-4057-a530-91840c0d5401&DisplayLang=en

      

In questo articolo viene descritto come disattivare Business Contact Manager in Microsoft Office Outlook 2007 con Business Contact Manager e in Microsoft Office Outlook 2003 con Business Contact Manager.

È possibile utilizzare l’elemento Installazione applicazioni nel Pannello di controllo per rimuovere Business Contact Manager. Tuttavia, se si desidera disattivare Business Contact Manager senza rimuovere Business Contact Manager, eseguire la procedura:

Uscire da Outlook.

Fare clic sul pulsante Start , scegliere Esegui , digitare regedit e quindi fare clic su OK.

Individuare e selezionare la seguente sottochiave del Registro di sistema:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\

Outlook\Addins\Microsoft.BusinessSolutions.eCRM.OutlookAddIn.Connect.1

Fare clic con il pulsante destro del mouse su LoadBehavior e quindi fare clic su Modifica.

Nella casella dati valore digitare 1 e quindi fare clic su OK.

Chiudere l’editor del Registro di sistema.

Avviare Outlook.

Per attivare Business Contact Manager dopo che è stato disabilitato Business Contact Manager, attenersi alla seguente procedura:

Uscire da Outlook.

Fare clic sul pulsante Start , scegliere Esegui , digitare regedit e quindi fare clic su OK.

Individuare e quindi scegliere seguenti sottochiave del Registro di sistema:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\

Outlook\Addins\Microsoft.BusinessSolutions.eCRM.OutlookAddIn.Connect.1

Fare clic con il pulsante destro del mouse su LoadBehavior e quindi fare clic su Modifica.

Nella casella dati valore digitare 3 e quindi fare clic su OK.

Chiudere l’editor del Registro di sistema.

Avviare Outlook.

      

Di seguito il link da dove si può scaricare la Planning Guide di Microsoft Office Communication Server 2007 che, da pagina 74, illustra i requisiti di sistema e di network necessari, fornendo una comparativa tra diversi scenari.
 
Office Communications Server 2007 Document: Planning Guide:
http://www.microsoft.com/downloads/details.aspx?familyid=723347c6-fa1f-44d8-a7fa-8974c3b596f4&displaylang=en

      

Per me sono iniziate le vacanze, che dureranno relativamente poco perché il 29 sarò nuovamente in ufficio, ad aprofittare delle ferie degli altri per fare un po’ di manutenzione sui server. Nel frattempo faccio gli auguri di buon natale e felice anno nuovo a tutti!

      

allocPSA è una suite di applicazioni sviluppata per le piccole e medie imprese, che vogliono ottenere una migliore redditività, migliorando l’efficenza del personale attraverso l’ottimizzazione del tempo produttivo, una migliore pianificazione ed una gestione integrata dei clienti.

Il programma è stato sviluppato in PHP e si interfaccia ad un database MySQL, è rilasciato sotto licenza GPL ed è in lingua inglese.

allocPSA permette di:

• gestire singoli clienti in maniera illimitata;
• gestire società illimitate;
• gestire note clienti;
• gestire documenti clienti;
• avere una panoramica completa dei progetti avviati per ogni cliente.

Link per il download

      

Dal seguente sito http://www.microsoft.com/downloads/details.aspx?FamilyID=ae7387c3-348c-4faa-8ae5-949fdfbe59c4&DisplayLang=it potete scaricare la Service Pack 3 per Microsoft SQL Server 2005.

Mentre da questo sito http://www.microsoft.com/downloads/details.aspx?FamilyID=3181842a-4090-4431-acdd-9a1c832e65a6&DisplayLang=it la Service Pack 3 per la versione Express.

Aggiornata anche la documentazione in linea, scaricaribile dal seguente sito http://www.microsoft.com/downloads/details.aspx?FamilyID=be6a2c5d-00df-4220-b133-29c1e0b6585f&DisplayLang=it

      

Oggi doppio post, infatti oggi ho scoperto due cose nuove. Dopo la nuova procedura purge del package dbms_shared_pool di cui ho parlato nel post precedente adesso è il momento di un nuova cosa che ho scoperto grazie a questo thread di CDOS. Si tratta di un comportamento di SQL*Plus, ma più in generale di Oracle. Ne ha scritto Eddie Awads più di tre anni fa ma io credo di non essermene mai accorto.

SQLPlus all’uscita (tramite comando EXIT o DISC) fa un commit implicito. La documentazione lo specifica, ma chi è mai andato a vedere la descrizione del comando exit sul manuale? Chiaramente chi lavora con Oracle impara abbastanza presto che bisogna sempre fare dei commit impliciti o espliciti e così è stato per me. Se sono uscito da sqlplus senza fare commit o rollback espliciti è perché non avevo modificato dati importanti, quindi non ho mai verificato il comportamento e quindi non ho mai capito che all’uscita veniva fatto un commit esplicito.

Ero convinto che il comportamento fosse lo stesso di quando una sessione in qualche modo “crasha” ed oracle la ripulisce facendo il rollback. Non è così. Chiaramente, nei programmi  a interfaccia grafica il problema non si pone. Ad esempio con SQL Developer all’uscita viene chiesto se committare o rollbackare (c’è anche una terza opzione che stronca brutalmente la connessione lasciando la sessione ed eventuali transazioni appese , ho provato e ne sconsiglio l’uso). In sqlplus invece la cosa è subdola.

Ho fatto anche un test con JDBC e con mia grande sorpresa (di nuovo) ho scoperto che anche qui il comportamento è lo stesso, come documentato la chiusura della connessione fa un commit implicito.

Questo comportamento si chiama (almeno credo) Commit on Exit. E’ diverso dal meccanismo chiamato autocommit che abilita il lancio di un commit automatico dopo ogni istruzione DML.

      

In questo blog  ho scritto più volte sull’argomento performance tuning con particolare riguardo ai problemi di “instabilità dei piani di esecuzione” che l’accoppiata CBO e bind variables. Da diverso tempo non mi capitano casi di query con piani esecuzione sballate (direi che è una cosa positiva), però alcuni mesi fa ho avuto un incontro presso un cliente con il suo, assieme ad un consulente Oracle per formare il DBA su come affrontare casi di query con piani di esecuzione sballati che bloccano il sistema. Infatti in precedenza c’era stato un caso simile e sia da parte mia che da parte dello stesso consulente Oracle sentito al telefono erano state suggerite due strade: il ricalcolo delle statistiche su una delle tabelle interessate o il flush della shared pool, con in rischio però che quest’ultima soluzione non fosse certa, perchè se durante il flush il piano è utilizzato, esso è “pinned” cioè bloccato e non viene espluso dalla cache. Stiamo parlando di azioni d’emergenza per sbloccare un sistema con il quale lavorano centinaia di operatori.

Un punto emerso in quell’occasione, come in altre, era il fatto che non c’era un metodo per cacciare dalla cache sono un preciso piano di esecuzione. Bene, oggi, grazie a questo post di Doug Burns, ho scoperto non solo che questo è possibile in 11g, ma anche, leggendo il post citato di Fairlie Rego, che con una patch applicabile dalla versione 10.2.0.2 è possibile anche su 10gR2.

DBMS_SHARED_POOL.PURGE

In Oracle 11g è stato aggiunto un nuovo met0do PURGE al vecchio package DBMS_SHARED_POOL, che permette di espellere singoli oggetti dalla shared pool come ad esempio singoli cursori (e quindi il relativo piano di esecuzione). Fairlie Rego fa un esempio. Non ho capito bene come si valorizza il parametro heaps ne quali sono i possibili valori (a parte il 65 usato nell’esempio). Da quel che si deduce dall’esempio in ogni caso, si elimina dalla cache tutto il cursore e suppongo anche tutti i figli (child)  e i loro piani di esecuzione. Esiste una nota Metalink, la 457309.1, che spiega abbastanza bene uso e disponibilità di questa caratteristica.

Riguardo al disponibilità ho notato una cosa bizzarra, nella nota metalink 457309.1 spiega che questo nuova procedura è disponibile come patch per le versioni 10.2.0.2 e 10.2.0.3 ed è inclusa nella patch set 10.2.0.4 (oltre alla versione 11g). A questo proposito ho notato una cosa bizzarra, controllando su una nostra installazione 10.2.0.4 Enterprise Edition non ho trovato traccia del package DBMS_SHARED_POOL, su una analoga installazione, ma Standard Edition c’è il package con tanto di procedura PURGE. Su una istanza 10.2.04 Entrerprise Edition che uso per test miei il package c’è , con la procedura PURGE. Infine sull’istanza di test 11.1.0.7, Enterprise Edition, il package c’è.

Nella documentazione del package, relativa alla versione 11g,  ho notato che si specifica che il package non viene creato sulla versione standard edition (come mai?). Ho provato a dare un’occhiata allo script di creazione dal quale si ho solo notato come la modifica relativa alla nuova procedura risalga nientemeno che ad agosto 2006.

Sulla documentazione della 10gR2 invece si dice solo che la creazione del package non è in clusa nello script catproc.sql. In effetti non ho trovato dove tale creazione sia invocata, ma su tutti i miei 10g con versione <10.2.0.4 il package è installato.

Sull’istanza 10.2.0.4 Enterprise Edition dove il package non è installato pare vi sia stato un backporting al contrario della 11g, nel senso che l’applicazione del patchset ha rimosso dalle procedure di creazione del database l’installazione del package in caso di Enterprise Edition. Infatti su quella macchina ho installato la patchset prima di creare il database. Su una istanza simile su cui ho seguito lo stesso procedimento ma ho installato Standard Edition il package c’è.

Sulla istanza di test con 10.2.0.4 Enterprise Edition la patchset 10.2.0.4 l’ho installata dopo la creazione del database (creazione avvenuta con la versione 10.2.0.3), quindi il package era già installato ed è stato “patchato” aggiungendo la nuova procedura”.

Conclusione

A parte quindi le variabili che condizionano l’installazione di default del package (mi chiedo se la sua installazione sia rischiosa), la sostanza è che Oracle ha aggiunto uno strumento che in particolari situazioni può essere utile (se funziona veramente :)).

A pensarci bene, nelle situazioni che ho visto io probabilmente ci sarebbe comunque dovuto essere uno stop di tutti gli operatore per impedire l’invocazione della query con conseguente pinning e impossibilità di rimuovere il piano di esecuzione della query.

P.S.

Terminata la scrittura di questo post ho continuato la lettura dei post indicati da Doug Burns, in particolare questo. Viene segnalato che su 10.2.0.4  la procedura DBMS_SHARED_POOL.PURGE non funziona e si rimanda alla nota metalink Note:751876.1 la quale in conclusione spiega che la procedura è “event protected”  quindi va abilitata esplicitamente tramite parametro nel init.ora, settando l’evento 5614566 (che è anche il numero della patch).  Questo rende un po’ la vita difficile

      

Alcuni giorni fa ho scritto un post in cui descrivevo un’implementazione artigianale ed ingenua di una soluzione di “alta affidabilità” o “disaster recovery”. La soluzione da me implementata si basava su export/import dello schema database di interessa da una macchina all’altra.  Sono contento di aver scritto tale post, ma soprattuto sono grato ad Alessandro per avermi segnalato un link a un documento  di Niall Lichtfield (il documento sta ancora sul vecchio sito di Niall) in cui si parla di una soluzione “Data Guard” per Oracle Standard Edition.

Confesso che tempo fa gia un’altra persona mi aveva detto di aver messo in piedi una soluzione Data Guard “manuale” su Oracle database Standard Edition. Non ho mai approfondito la cosa perchè mi sembrava una cosa poco pulita (nel senso al limite della “legalità”). L’accenno al fatto che una implementazione manuale di “Data Guard” può essere fatta su Standard Edition nella presentazione di Niall mi  ha spinto a fare una ricerca approfondita. Sono partito dal listino dove in realtà non ho trovato niente.  Alla fine sono andato sulla documentazione e con mia grande soddisfazione ho trovato questo.  Quindi Oracle dichiara espressamente che l’implementazione manuale di uno Standby Database è possibile su Standard Edition. A questo punto ho deciso si fare dei test, essendo una cosa che sicuramente sul lavoro mi servirà.

Siccome sulla documentazione Oracle si da spazio solo all’implementazione “Enterprise” di “Data Guard” ho cercato su internet qualche documento ed ho trovato questo interessante articolo su www.databasejournal.com.

Sospesi i test con Oracle 11g ho clonato la macchina virtuale con Oracle 10gR2 che ho usato per altri test e seguito le semplici istruzioni riportate sull’articolo, ho fatto un po’ di controlli incrociati con il documento e gli script di Niall Lichtfield e la documentazione della 10gR2. Ad esempio nell’articolo c’è l’indicazione di eseguire il comando

ALTER SYSTEM ARCHIVE LOG START;

cosa che con 10g non è più necessaria e deprecata (il comando non da errore ma non fa nulla, rif)

Una cosa che mi capita è che il “recover” dell’istanza di standby da sempre errore:

SQL> alter database recover automatic standby database until cancel;
alter database recover automatic standby database until cancel
*
ERROR at line 1:
ORA-00279: change 16718544 generated at 12/17/2008 12:00:44 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf
ORA-00280: change 16718544 for thread 1 is in sequence #619
ORA-00278: log file ‘/opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf’ no
longer needed for this recovery
ORA-00308: cannot open archived log
‘/opt/oracle/oradata/inarchivelogs/1_619_645973149.dbf’
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Il numero di sequenza che cerca è quello del log corrente sull’istanza primaria. Credo che sia normale, perchè per il resto funziona tutto, infatti, prima di questo recorery (e dopo aver creato l’istanza di standby, tra l’altro con un backup a freddo copiando semplicemente tutti i datafile) ho lanciato sull’istanza principale

SQL> @?/rdbms/admin/utlsampl.sql

Che crea lo schema SCOTT e dopo il recovery sulla istanza di standby:

SQL> alter database recover cancel;

Database altered.

SQL> alter database open read only
2  /

Database altered.

SQL> conn scott/tiger
Connected.
SQL> select count(*) from user_tables;

COUNT(*)
———-
4

Infine ho fatto una prova di “switch-over”, infatti il segreto di ogni buona politica di backup è un test di ripristino. Nell’articolo di Databasejournal.com la fa facile, dicendo che basta applicare tutto il redo mancante e poi aprire in modalità read write. Io non ho trovato subito  un modo diretto per aprire in modalità read write il datbase. Seguendo le indicazioni del manuale non funziona  (credo dipenda sempre dal fatto che nel manuale è descritta solo la gestione automatica):

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

SWITCHOVER_STATUS
——————–
NOT ALLOWED

Ci sono riuscito ripristinando i controlfile di partenza, facendo un recovery incompleto e aprendo con l’opzione RESETLOGS (gli online redolog non li avevo copiati).

Tutti gli altri tentativi di aprire il database in modalità read write con i controlfile usati per lo standby mi davano:

ORA-01666: control file is for a standby database

Cercando meglio ho trovato la soluzione, qui.

SQL> alter database ACTIVATE STANDBY DATABASE;

Database altered.

SQL> alter database open;

Database altered.

SQL> conn scott/tiger
Connected.
SQL> create table pluto (a number);

Table created.

Qui, dice che è meglio non usare ALTER DATABASE ACTIVATE STANDBY DATABASE perché si rischia di perdere dati, ma sospetto che nella gestione manuale non vi siano molte alternative.

L’unico difetto di questa tecnica di “alta affidabilità” o “disaster recovery” come la si vuole classificare, è secondo me il fatto che la seconda istanza non può essere usata, se non in modalità read-only.  Non ho indagato a fondo, ma immagino che sia possibile usare solo physical standby database e non logical standby database con la Standard Edition.

      

I miei test interni con Oracle 11g su Linux 64 bit di cui ho già scritto in due post precedenti (questo e questo) sono proseguiti a singhiozzo. Qualche giorno fa sono riuscito a installare la patchset 11.1.0.7.0 e i risultati sono a dir poco sorprendenti, ho rilanciato più volte le stesse query che in precedenza di davano errori ORA-00600 e ORA-07445 e queste hanno girato senza alcun problema. Ho rilanciato altre query di update che hanno girato per ore senza alcun problema. Quindi sembra la patchset 11.1.0.7  sistemi realmente qualche problemino presenta sulla prima “release” di Oracle 11g.

L’update che mi ero inventato è andato a buon fine ed ha fatto ciò che in effetti mi aspettavo, però non era sufficente, quindi ho utilizzato un’altro update utilizzando le funzioni del package DBMS_RANDOM per generare delle stringhe casuali ed avere dei valori più distribuiti.

Alla fine però per riprodurre il comportamento descritto da Christian Antognini ho dovuto utilizzare due metodi alternativi: hint oppure parametro optimizer_mode=first_rows_100.

SQL> select * from customers where cust_last_name like ‘cudiz%’;

Execution Plan
———————————————————-
Plan hash value: 2008213504

——————————————————————————-
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
——————————————————————————-
|   0 | SELECT STATEMENT  |           | 11426 |  1015K|  5625   (2)| 00:01:08 |
|*  1 |  TABLE ACCESS FULL| CUSTOMERS | 11426 |  1015K|  5625   (2)| 00:01:08 |
——————————————————————————-

SQL> select * from customers where cust_last_name like ‘cudiz%’;

Execution Plan
———————————————————-
Plan hash value: 3995041806

—————————————————————————————–
| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
—————————————————————————————–
|   0 | SELECT STATEMENT            |           |   100 |  9100 |   113   (0)| 00:00:02 |
|   1 |  TABLE ACCESS BY INDEX ROWID| CUSTOMERS |   100 |  9100 |   113   (0)| 00:00:02 |
|*  2 |   INDEX RANGE SCAN          | TEST_IDX  |       |       |    13   (0)| 00:00:01 |
—————————————————————————————–

Francamente trovo curioso come negli esempi di Antognini, in cui crea una tabellina minuscola con 10 record, Oracle 11g vada senza indugio per indice, cosa  apparentemente poco sensata. In realtà mentre scrivevo mi è venuto in mente che probabilmente in questo caso Oracle usa l’istogramma per capire subito che il valore usato dalla query non c’è. Avevo il dubbio che oracle facesse più lavoro andando sul ‘indice per poi dover andare anche sulla tabella, ma non essendoci il valore cercato, il passaggio sulla tabella non c’è. In più ho notato che forzando un full scan sulla tabella oracle fa 3 consistent gets, contro l’1 che fa quando va solo sull’indice, quindi ha ragione lui.

Nel mio caso invece i valori distinti sono oltre due milioni (quasi tutti). Questo fa si che l’istogramma, che può avere al massimo 254 bucket, è per forza approssimato. Rimango perplesso però, perchè dal piano che ho riportato sopra sembra che l’ottimizzatore stimi di estrarre 11426 righe, stima si sbagliata in eccesso, ma che significa comunque meno dell’1% dei numero totale di record presenti nella tabella e nonostante ciò l’ottimizzatore preferisce un full scan. La differenza nei tempi si sente, perchè con l’indice la risposta è pressoché immediata.

Si tratta di test approssimativi, infatti non ho mai avuto problemi con le ricerche per Like sull’applicazione sviluppata nella mia azienda, non è escluso però che si presentino, quindi sicuremente questo test mi tornerà utile e lo approfondirò.

      

1.Open the SQL Server management studio
2.Connect to SQL Server using windows authentication
3.Right click the server name and choose properties
4.Go to security tab. Change server authentication to “SQL Server and Windows Authentication mode”
5.Click OK and restart SQL Server
6.Go to SQL Server studio management
7.Expand the server and choose security and expand logins
8.Right click on SA, from properties modify the password and confirm password

OR

To reset the sa password, you can make the following:
1. Login to the SQL Server box as the Administrator.
2. Run SQL Server Enterprise Manager.
3. Right-click the server name and choose ‘Edit SQL Server Registration properties’.
4. Choose ‘Use Windows authentication’ and click OK button.
5. Expand a server, expand a Security and click Logins.
6. Double-click the sa login and specify new password on the General tab. (enable Login to)

Or You Can Use

USE [master]
GO
ALTER LOGIN [sa] WITH DEFAULT_DATABASE=[master],
DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=ON, CHECK_POLICY=ON
GO
USE [master]
GO
ALTER LOGIN [sa] WITH PASSWORD=N’<insert_new_password_here>’ MUST_CHANGE
GO

or

From a command prompt
OSQL -S <insert_servername_here> -E
1> EXEC sp_password NULL, ‘<insert_new_password_here>’, ’sa’
2> GO

      

Finalmente, oggi Oracle mi ha comunicato di aver verificato il mio ” OCP Hands-On Course Requirement”. E’ stato una cosa abbastanza lunga direi. Due giorni fa via e-mail mi hanno richiesto i dati del corso che ho frequentato, comunque dopo 22 giorni finalmente posso affermare di essere OCP.

      

Oggi avrei voluto scrivere un post sui miei test con Oracle 11g e la patchset 11.1.07, oppure un post sulle funzioni analitiche CUBE e ROLLUP, ma mi è capitata una storia degna della sala macchine. L’epilogo della storia mi ha talmente sconvolto che non sono riuscito a trattenermi dall’attaccarmi al PC per scriverla, dunqu partiamo dall’inizio.

Stamattina mi è stato chiesto di controllare un database presso un nostro cliente perchè l’applicazione dava strani errori. Il database in questione è un 10gR2 su Linux Suse9 64 bit e come prima cosa ho provato a connettermi via ssh alla macchina, ma il mio putty mi dava un errore. Nell’impossibilità di accedere alla macchina contattiamo un sistemista che lavora presso il cliente e gli chiediamo di verificare sulla console della macchina se vi sono problemi. Questi rileva che ci sono degli errori, fa una foto al monitor e ce la manda. Dalla foto si vedono strani errori legati all’esecuzione dello script  di avvio del database al boot della macchina. Di seguito poi un messaggio segnala che vari servizi, fra cui sshd non sono stati avviati.

Non comprendendo il motivo degli errori dello script di avvio del database contatto direttamente il sistemista e gli chiedo di loggarsi dalla console e gli chiedo di provare ad avviarmi il servizio sshd, ma questi mi dice che il comando da un errore tipo “file non trovato”. Molto perplesso, cerco di capire qualcosa, guidando il sistemista per indagare (è molto difficile capire un problema su una macchina senza avere accesso alla console). Dopo un po’ di indagini capisco che sul server manca la directory /usr. Tutto il resto pare essere al suo posto, compresa l’installazione di oracle sotto /opt.

Una situazione simile non poteva non farmi venire in mente l’episodio “Return of the Sysadmin“. Non risultavano guasti hardware, i dischi sono in raid 1, manca una sola directory e tutto il resto è li al suo posto. Ho subito dato un’occhiata al .bash_history dell’utente root, ma li non c’era nulla di strano.

Escludendo quindi un gesto maldestro rimaneva come ipotesi una bizzarra corruzione del filesystem. Ho provato a consultare un collega per chiedere aiuto ma anche lui si è trovato in difficoltà, senza accesso diretto alla macchina e senza la directory /usr mancano tutti gli strumenti per fare una diagnosi.

Alla fine, come tentativo disperato abbiamo provato a copiare, tramite chiave usb, la directory /usr da un’altra macchina con una installazione analoga. Con qualche difficoltà ce l’abbiamo fatta e siamo riusciti a riavere il servizio ssh e a riavviare Oracle.

Riavuto quindi l’accesso diretto via ssh ho dato un’occhiata al file /var/log/messages (che come ha detto il sistemista, più pratico di windows che di *NIX è un po’ come l’event viewer :)) e in corrispondenza di ieri noto dei strani messaggi che sembrano riguardare gnome (una delle interfacce grafiche di linux) . A questo punto sono tornato a spulciare sotto /root, e che ci trovo? una bella directory .Trash ma soprattutto, dentro la .Trash ci trovo la usr scomparsa. Chiaramente qualcuno maldestramente dall’interfaccia grafica ha cancellato quella benedetta directory.

      

È nata JikiBloom, la prima suite completamente Open Source dedicata al mondo della Piccola e Media Impresa. JikiBloom integra i più quotati applicativi Open Source a livello internazionale per la gestione dei processi aziendali in un’unica soluzione, flessibile e modulare.
https://jikibloom.dev.java.net/

      

Code Name: WSS with SP1
Windows SharePoint Services 3.0 with SP1
x86
x64
Code Name: WSS Infra Update
Infrastructure Update for Windows SharePoint Services 3.0
x86
x64
Code Name: WSS LP
Windows SharePoint Services 3.0 Language Pack
x86
x64
Code Name: WSS LP SP1
Windows SharePoint Services 3.0 Language Pack SP1
x86 
x64
Code Name: MOSS
Microsoft Office SharePoint Server 2007 With Service Pack 1
x86
x64
Code Name: MOSS Infra Update
Infrastructure Update for Microsoft Office Servers (KB951297)
x86
x64
Code Name: MOSS LP
Language Packs for SharePoint Server 2007
x86
x64
Code Name: MOSS LP SP1
The 2007 Microsoft Office Servers Language Pack Service Pack 1 (SP1)
x86
x64

      

Now finally we have a single source that you can find best practices around Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007.

http://technet.microsoft.com/en-us/office/sharepointserver/bb736746.aspx

      

Alcuni giorni fa ho avuto richiesta/necessità di sviluppare una procedura per sincronizzare due database su due macchine. In sostanza il concetto è quello di mettere in piedi un sistema ad alta affidabilità (HA) ovvero con un database attivo ed uno in stand-by da utilizzare in caso di problemi al primo.  Il tutto con versione standard edition, su due macchine sulla stessa rete ma senza storage condiviso e senza necessità di sincronizzazione continua. Quindi, trattandosi del database della nostra applicazione, che si basa su un unico schema l’idea più semplice era quella di un export dello schema sulla prima macchina e di un import sulla seconda. Non è un’idea sofisticata, ma sufficente a coprire l’esigenza del cliente.

Oracle Data Pump

Con la versione 10g Oracle ha introdotto questo nuovo strumento di esportazione dei dati, molto più veloce e flessibile del vecchio “export”, questo strumento si chiama appunto Data Pump ed ha sia un interfaccia tramite eseguibili da linea di comando (expdp/impdp) che una API PL/SQL. Fino a un paio d’anni fa però la maggior parte dei database che avevo in gestione era 9iR2 e quindi non ho mai utilizzato seriamente Data Pump.  Nell’ultimo anno ho cominciato ad utilizzarlo un po’ di più ed ora sta diventando lo strumento privilegiato per le operazioni che facevo con exp/imp.

Nel caso della procedura che dovevo realizzare c’erano due caratteristiche interessanti di Data Pump: l’API PL/SQL e la possibilità di fare direttamente l’import in un database via Database Link, quindi senza necessità di esportare su file da una parte e importare dall’altra; sul database dove si vuole importare si fa un database link che punta al database “sorgente” e poi si può importare usando il parametro NETWORK_LINK invece che DUMPFILE.

La mia procedura quindi doveva fare due passi:

1. spianare lo schema
2. reimportarlo

Per poter spianare lo schema almeno parte della procedura doveva eseguire una operazione privilegiata, quindi ho pensato di crearla direttamente da utente SYSTEM.  Questo crea un problema, infatti alla chiamata di dbms_datapump.open( la mia procedura mi dava un errore di privilegi. Le mie ricerche non mi hanno aiutato, fino a quando per fortuna mi è venuta l’idea di provare con il comando impdp, il quale mi ha dato un’informazione in più:

ORA-39149: cannot link privileged user to non-privileged user

Questa mi ha condotto fortunatamente alla nota metalink 351598.1, la quale dice che in pratica l’utente a cui si collega il database link deve avere il privilegio EXP_FULL_DATABASE. Già, perchè il mio database link invece si collegava con l’utente proprietario dello schema che “copiavo”.  Sempre senza farmi troppi problemi ho usato anche li l’utente SYSTEM.

Quindi, come promemoria riporto il testo della procedura:

create or replace procedure reloadUserSchema AUTHID CURRENT_USER is
v_handle number;
BEGIN
EXECUTE IMMEDIATE ‘DROP USER USERX CASCADE’;
v_handle := DBMS_DATAPUMP.OPEN(’IMPORT’, ‘SCHEMA’, ‘MYDBLINK_SYSTEM’, ‘USERX_IMPORT’);
DBMS_DATAPUMP.METADATA_FILTER(handle=>v_handle, name=>’SCHEMA_LIST’,
value=>’USERX’, object_path=>NULL);
DBMS_DATAPUMP.METADATA_REMAP(handle=>v_handle, name=>’REMAP_SCHEMA’,
ld_value=>’USERX’, value=>’USERX’);
DBMS_DATAPUMP.ADD_FILE(handle=>v_handle, filename=>’importgeocall.log’,
directory=>’LOG_IMPDP’, filetype=>DBMS_ DATAPUMP.KU$_FILE_TYPE_LOG_FILE);
DBMS_DATAPUMP.START_JOB(handle=>v_handle);
END;
/

Nota

Nelle mie ricerche sono ripassato in un post di Diego di qualche tempo fa. Io al tempo (neanche tanto tempo fa) non mi interessavo molto di data pump e non mi ricordavo più di tale post. Però ho notato un problema con gli apici.  Ho cercato di aggiungere un commento e non ci sono riuscito allora scrivo qui. Lui, utilizza il triplice apice singolo, come nell’articolo che ha trovato,  e non gli funziona. La documentazione in effetti è vaga. Io distrattamente ho usato l’apice singolo in maniera semplice ed ho appurato che funziona. In effetti ho visto che anche alcune procedure del package DBMS_SCHEDULER accettano come parametri stringhe con nomi di oggetti separati da virgole semplicemente. Evidentemente queste procedure sono in grado poi di fare un semplice “parsing” dei parametri. Quindi in sintesi facendo:

DBMS_DATAPUMP.METADATA_FILTER(handle=>v_handle, name=>’SCHEMA_LIST’,
value=>’USERX,USERY’, object_path=>NULL);

La procedura funziona correttamente “filtrando” gli schemi USERX e USERY.