Showing posts with label packages. Show all posts
Showing posts with label packages. Show all posts

Friday, March 23, 2012

How could XML help us in our ETL packages on daily-basis?

Hi all of you,

I'm just a newbie with XML. Now we're moving all our DTS to SSIS packages. Most of them are simply processes that takes a plain file and loading these data into Sql table or in inverse way. So that I wonder what role will play XML here.

I mean, are there big differences between store data as XML format and nvarchar?

That sort of stuff.

Thanks in advance for any input,


http://msdn2.microsoft.com/en-us/library/ms187508.aspx

HTH

How could I do backups for my packages?

Hi all of you,

Formerly when we ran dts we had DtsBackup2000. So we could to arrange lots of backups around the network in a centralized way. But now how to run backups in groups no individually way?

We've got five sql25k along with its dtsx packages and we'd like have all of them in the same place.

Any tool or idea?

Thanks in advance,

What storage method do you use?

|||

Hi Darren,

Thanks for your answer. We've LEGATO system for our db. in regard packages we save them as .dtb and .dts files.

TIA

|||

I meant how do you store your SSIS packages, as that would impact what I suggest for a backup of them! I know about DTS, you told me you used DTSBackup.|||

Hi again,

Individually, people save them in its own local machines but, of course, that's not very safe.. I mean, VSS is not used at all.

The SSIS packages are stored on the production server and on the development server.

Up to the date the only way for me is do backup one after one.

Thanks Darren,

|||

All of them in MSDB.

I don't know if this answer finally clarifies this post.

|||

If the packages are deployed to MSDB as opposed to File System, backing up the SQL database on Production & Dev will effectively back up your packages.

Obvioulsy the "undeployed" latest or working versions on individual machines are at the mercy of the users! At least suggest they are saved on a network drive that is backed up if they cannot or will not use VSS. Local machine saves are madness Wink

|||

Hi Will,

Thanks for your answer. But our main idea is to retrieve as soon as possible a concrete dtsx without have to do a restore when there's an issue or problem.

|||

If that is the case, go overboard... save all packages to a shared drive on the network (make sure that your sql agent user / proxy has access). Back that up nightly and run all imports into your MSDB from this drive. Also, make sure that you are doing full backups of the sql server in test and prod.

//mycomputername/SSISPackages/PackageName(s)

//mycomputername/SSISPackages/ConfigFiles

backup all files in SSISPackages...

|||

enric, if you need to rollback to a working version of a SSIS package then I woudl look to re-deploy that working package from your release management store or source control system.

DTSBackup made sense in DTS because it was very common to change packages on the server, just because the tools worked that way, but with SSIS, you should always have an offline copy with changes made by the developer, and that "should" be under some control, source control, release management etc.

How could I do backups for my packages?

Hi all of you,

Formerly when we ran dts we had DtsBackup2000. So we could to arrange lots of backups around the network in a centralized way. But now how to run backups in groups no individually way?

We've got five sql25k along with its dtsx packages and we'd like have all of them in the same place.

Any tool or idea?

Thanks in advance,

What storage method do you use?

|||

Hi Darren,

Thanks for your answer. We've LEGATO system for our db. in regard packages we save them as .dtb and .dts files.

TIA

|||I meant how do you store your SSIS packages, as that would impact what I suggest for a backup of them! I know about DTS, you told me you used DTSBackup.|||

Hi again,

Individually, people save them in its own local machines but, of course, that's not very safe.. I mean, VSS is not used at all.

The SSIS packages are stored on the production server and on the development server.

Up to the date the only way for me is do backup one after one.

Thanks Darren,

|||

All of them in MSDB.

I don't know if this answer finally clarifies this post.

|||

If the packages are deployed to MSDB as opposed to File System, backing up the SQL database on Production & Dev will effectively back up your packages.

Obvioulsy the "undeployed" latest or working versions on individual machines are at the mercy of the users! At least suggest they are saved on a network drive that is backed up if they cannot or will not use VSS. Local machine saves are madness Wink

|||

Hi Will,

Thanks for your answer. But our main idea is to retrieve as soon as possible a concrete dtsx without have to do a restore when there's an issue or problem.

|||

If that is the case, go overboard... save all packages to a shared drive on the network (make sure that your sql agent user / proxy has access). Back that up nightly and run all imports into your MSDB from this drive. Also, make sure that you are doing full backups of the sql server in test and prod.

//mycomputername/SSISPackages/PackageName(s)

//mycomputername/SSISPackages/ConfigFiles

backup all files in SSISPackages...

|||

enric, if you need to rollback to a working version of a SSIS package then I woudl look to re-deploy that working package from your release management store or source control system.

DTSBackup made sense in DTS because it was very common to change packages on the server, just because the tools worked that way, but with SSIS, you should always have an offline copy with changes made by the developer, and that "should" be under some control, source control, release management etc.

How could I do backups for my packages?

Hi all of you,

Formerly when we ran dts we had DtsBackup2000. So we could to arrange lots of backups around the network in a centralized way. But now how to run backups in groups no individually way?

We've got five sql25k along with its dtsx packages and we'd like have all of them in the same place.

Any tool or idea?

Thanks in advance,

What storage method do you use?

|||

Hi Darren,

Thanks for your answer. We've LEGATO system for our db. in regard packages we save them as .dtb and .dts files.

TIA

|||I meant how do you store your SSIS packages, as that would impact what I suggest for a backup of them! I know about DTS, you told me you used DTSBackup.|||

Hi again,

Individually, people save them in its own local machines but, of course, that's not very safe.. I mean, VSS is not used at all.

The SSIS packages are stored on the production server and on the development server.

Up to the date the only way for me is do backup one after one.

Thanks Darren,

|||

All of them in MSDB.

I don't know if this answer finally clarifies this post.

|||

If the packages are deployed to MSDB as opposed to File System, backing up the SQL database on Production & Dev will effectively back up your packages.

Obvioulsy the "undeployed" latest or working versions on individual machines are at the mercy of the users! At least suggest they are saved on a network drive that is backed up if they cannot or will not use VSS. Local machine saves are madness Wink

|||

Hi Will,

Thanks for your answer. But our main idea is to retrieve as soon as possible a concrete dtsx without have to do a restore when there's an issue or problem.

|||

If that is the case, go overboard... save all packages to a shared drive on the network (make sure that your sql agent user / proxy has access). Back that up nightly and run all imports into your MSDB from this drive. Also, make sure that you are doing full backups of the sql server in test and prod.

//mycomputername/SSISPackages/PackageName(s)

//mycomputername/SSISPackages/ConfigFiles

backup all files in SSISPackages...

|||

enric, if you need to rollback to a working version of a SSIS package then I woudl look to re-deploy that working package from your release management store or source control system.

DTSBackup made sense in DTS because it was very common to change packages on the server, just because the tools worked that way, but with SSIS, you should always have an offline copy with changes made by the developer, and that "should" be under some control, source control, release management etc.

Monday, March 12, 2012

How can we compare other data mining software packages with SQL Server 2005 Data mining?

Hi, all experts here,

I would like to know if there is any way to migrate third-party data mining packages with SQL Server 2005 data mining algorithms together then we can have a comparison among all of them to get the best results for training models.

I am looking forward to hearing from you.

Thanks a lot.

With best regards,

Yours sincerely,

Some vendors, e.g. KXEN and Angoss, offer plug-in algorithms that you can use for direct comparison. With others you may be able to use PMML to import models created with their tools into SQL Server 2005. SQL Server 2005 supports PMML 2.1 for Decision Trees and Clustering.

See books online for the supported PMML statements and how to extract PMML and create models from PMML.

Wednesday, March 7, 2012

how can i view the design of the ssis package after migration

OK, I was able to successfully migrate all of my DTS packages to SSIS, for SQL 2005. I can log into intergration services and see my packages listed under:

servername --> stored packages --> msdb. Now my question is, how can I open these packages, not run them open them in a design mode like you can in SQL 2000, you can double click on the package name and view the design of the package. how can i do that now that I have them in SQL 2005?

Right click on the package and select "Export..."

Chose File System as the destination and once done filling in the fields, you'll be able to open that package up in Business Intelligence Developer Studio.|||

Thanks, I tell ya, I should have walked away from this project when it was brought to me. Smile

Coming from coding .NET apps for the pass 6 years, this SQL style work is a whole new world to me.

|||It gives it a .dstx extension, is that correct?|||Yep, it sure is correct.|||

ok, thanks