Sql ANSI Padding: clustering

hi,

as we know we get clustering algorithm with managed plugin algorithm API

does anyone have developed any other plugin algorithm as i want to check what are the things that needs to be modified. i am not data mining algorithm developer but i just want to check where we have to make changes. i would be better if i get source code for algorithm other than clustering

ANOTHER PLUGIN ALGORITHM REQURIED?

thanks in advanced

We haven't made any other samples available as of yet. Angoss and KXEN, among others, both have implemented plug-in algorthms that they sell commercially. I don't know of any parties that have made source code available for their plug-ins - maybe someone will start?|||

is it possible to get detailed class diagram of DMPluginwrapper?

because i want to understand it in detail, as i want to implement framework in c# (totally) but before that i want to understand current architecture in detail.

|||

All the classes in the DMPluginWrapper are fully documented in the CHM help file that is included in the sample. Is there something missing from that?

A diagram of the interactions (in the COM system) for DM plug-in algorithms can be found here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/ssdmpia.asp

I think I mentioned before, I am not sure what kind of benefits can be obtained from re-implementing all the framework in C#. The COM interop layer must be there, anyway, and whether it is developed in C# or managed C++, the differences are just syntax elements.

Also, related to your initial question: I have developed a few different (incomplete) algorithms using the framework. Typically, a predictive algorithm (such as a classification or regression solution) requires a subset of the features included in the sample for the clustering algorithm. The cluster specific features are:

- CaseLikelihood and Clustermembership (in the algorithm class)

- the "*Cluster*" functions in the list of standard supported functions of the Metadata class

- the Cluster viewer in the Metadata class

If you remove these, your algorithm is not a clustering algorithm anymore. However, the remaining code should be enough for classification, regression or association types of algorithms. Of course, you will still need to implement your own training and prediction mechanism (specific to your algorithm)

Hope this helps

Using Windows clustering requires too long a failover time for my company's
uptime requirements. While SQL 2005's mirroring decreases the failover
time, it also only allows me to mirror to one server, thus putting me in a
rough spot for DR.
Is there any Oracle RAC type equivalent functionality (i.e. shared cache)
planned for future versions of SQL 2005, or available via some 3rd party
today for use with SQL 2005 today? The net is, I need as little downtime as
possible, both within a site, and across to my DR site (and as little to no
data loss as possible to that DR site)...all the while (of course)
minimizing the perf hit all of this requires...though while perf needs to
still fall in acceptable ranges, better perf is not as important as faster
failover and no data loss.
Any help is appeciated.
Thanks
RAC is by no means a High Availability feature so I am confused as to the
subject. There is no SQL Server RAC equivalent in the current release for a
read write database. However there are several HA / DR features that SQL
Server has that people use every day to satisfy their HA / DR needs. How
fast the recovery and how little down time is usually more a factor of how
much money you wish to spend. For instance you can do mirroring to get fast
up time and use the SAN's features to do DR. This is just a simple example
and it will really depend on what you want, what you have to work with and
how much time and money youa re willing to put into it. You might want to
start here:
http://www.microsoft.com/sql/technologies/highavailability/default.mspx
Andrew J. Kelly SQL MVP
"Jim" <ilmm555@.yahoo.com> wrote in message
news:uimO$QJhHHA.4980@.TK2MSFTNGP02.phx.gbl...
> Using Windows clustering requires too long a failover time for my
> company's uptime requirements. While SQL 2005's mirroring decreases the
> failover time, it also only allows me to mirror to one server, thus
> putting me in a rough spot for DR.
> Is there any Oracle RAC type equivalent functionality (i.e. shared cache)
> planned for future versions of SQL 2005, or available via some 3rd party
> today for use with SQL 2005 today? The net is, I need as little downtime
> as possible, both within a site, and across to my DR site (and as little
> to no data loss as possible to that DR site)...all the while (of course)
> minimizing the perf hit all of this requires...though while perf needs to
> still fall in acceptable ranges, better perf is not as important as faster
> failover and no data loss.
> Any help is appeciated.
> Thanks
|||OK, while RAC's original intent is to be a scale out feature, it's also very
much an HA feature...as if a node dies, other nodes press on...there's no
notion of "failover", thus eliminating the need to failover.
I disagree with it being "a factor of how much money you wish to spend"...as
regardless of how much you spend, the best you'll get SQL to is seconds of
downtime (with mirroring, likely 10s of seconds-minutes with
clustering)...thus, if you were to patch once a month (between SQL and
Windows this is certainly not out of the realm of possibility), that's
twelve failovers per year, at (at best...10 seconds of downtime each
failover)...so you're at 120 seconds a year...99.999% availability is 52.256
seconds...so you're already down to under 5 9's availability for the year.
In this shop, there's no notion of "unplanned downtime"...we're 24x7...it's
ALL downtime.
As for mirroring with SAN replicaiton for DR...below I mention no data loss,
so you'd be talking about synchronous mirroing WITH synchronous SAN
replication...while I said perf isn't the highest priority...I wonder how
slow it would be with effectively 3 writes for each write (one to the
primary SQL, one to the secondary SQL, one to the DR site...and since this
is all synchronous...all writes have to be completed before the
transaction's commited)...plus, now you're using SQL failover functionality
and SAN failover functionality...I certainly wonder how (operationally)
feasible this all will be...I'm sure it will be feasible, but certainly not
seamless...
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uPErZcShHHA.4064@.TK2MSFTNGP02.phx.gbl...
> RAC is by no means a High Availability feature so I am confused as to the
> subject. There is no SQL Server RAC equivalent in the current release for
> a read write database. However there are several HA / DR features that SQL
> Server has that people use every day to satisfy their HA / DR needs. How
> fast the recovery and how little down time is usually more a factor of how
> much money you wish to spend. For instance you can do mirroring to get
> fast up time and use the SAN's features to do DR. This is just a simple
> example and it will really depend on what you want, what you have to work
> with and how much time and money youa re willing to put into it. You might
> want to start here:
> http://www.microsoft.com/sql/technologies/highavailability/default.mspx
>
> --
> Andrew J. Kelly SQL MVP
> "Jim" <ilmm555@.yahoo.com> wrote in message
> news:uimO$QJhHHA.4980@.TK2MSFTNGP02.phx.gbl...
>
|||While RAC does give some flexibility in terms of a single node failure there
are still plenty of places that are close to single point of failure without
additional effort. And it does nothing for DR. Oracle or anyother rdbms has
no magic solution to guarantee 0 down time. It really boils down to the
limitations of hardware. You are not the 1st company looking for 24X7
operation. Hundreds if not thousands of companies use SQL Server every day
for 5 nines of availability. I disagree with the down time for the number
of patches. How often you patch is often up to you. I had a system running
for almost 3 years. It was secure and did what we wanted so we choose not to
patch it.
Andrew J. Kelly SQL MVP
"Jim" <ilmm555@.yahoo.com> wrote in message
news:eMz1vgVhHHA.1388@.TK2MSFTNGP05.phx.gbl...
> OK, while RAC's original intent is to be a scale out feature, it's also
> very much an HA feature...as if a node dies, other nodes press
> on...there's no notion of "failover", thus eliminating the need to
> failover.
> I disagree with it being "a factor of how much money you wish to
> spend"...as regardless of how much you spend, the best you'll get SQL to
> is seconds of downtime (with mirroring, likely 10s of seconds-minutes with
> clustering)...thus, if you were to patch once a month (between SQL and
> Windows this is certainly not out of the realm of possibility), that's
> twelve failovers per year, at (at best...10 seconds of downtime each
> failover)...so you're at 120 seconds a year...99.999% availability is
> 52.256 seconds...so you're already down to under 5 9's availability for
> the year. In this shop, there's no notion of "unplanned downtime"...we're
> 24x7...it's ALL downtime.
> As for mirroring with SAN replicaiton for DR...below I mention no data
> loss, so you'd be talking about synchronous mirroing WITH synchronous SAN
> replication...while I said perf isn't the highest priority...I wonder how
> slow it would be with effectively 3 writes for each write (one to the
> primary SQL, one to the secondary SQL, one to the DR site...and since this
> is all synchronous...all writes have to be completed before the
> transaction's commited)...plus, now you're using SQL failover
> functionality and SAN failover functionality...I certainly wonder how
> (operationally) feasible this all will be...I'm sure it will be feasible,
> but certainly not seamless...
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uPErZcShHHA.4064@.TK2MSFTNGP02.phx.gbl...
>
|||Hello Jim,
I am interested you say that SQL clustering is to slow. I run 8 production
clusters of various sizes, one is 300 GB just for data and fail over takes
about 30 seconds. Is 30 seconds to slow? If so then using a database mirror
would be the way to go. You will need to ensure that the client is using
ADO.NET 2.0 so that your failover is supported. However, there will be no
need to handle the failover as there is when using TAF on RAC.
Having said that currently SQL server has no RAC equivalency for scaling
out. If this is a requirement I would go with a HP Itanium system such as
the 6840 this would allow you to scale up over time rather than scaling out.
Let me know if you need clarification
John Vandervliet.
"Jim" <ilmm555@.yahoo.com> wrote in message
news:uimO$QJhHHA.4980@.TK2MSFTNGP02.phx.gbl...
> Using Windows clustering requires too long a failover time for my
> company's uptime requirements. While SQL 2005's mirroring decreases the
> failover time, it also only allows me to mirror to one server, thus
> putting me in a rough spot for DR.
> Is there any Oracle RAC type equivalent functionality (i.e. shared cache)
> planned for future versions of SQL 2005, or available via some 3rd party
> today for use with SQL 2005 today? The net is, I need as little downtime
> as possible, both within a site, and across to my DR site (and as little
> to no data loss as possible to that DR site)...all the while (of course)
> minimizing the perf hit all of this requires...though while perf needs to
> still fall in acceptable ranges, better perf is not as important as faster
> failover and no data loss.
> Any help is appeciated.
> Thanks
|||Do you run 8 production clusters where all of them are single instance
cluster..i.e one active and one passive or do you have a multi instance
cluster say more than 2 active nodes with 1 passive node for any of the
active nodes to failover.
"John Vandervliet" <jvandervliet@.SJRB.AD> wrote in message
news:7FE2AB87-4B70-44A0-8400-85B209FC6626@.microsoft.com...
> Hello Jim,
> I am interested you say that SQL clustering is to slow. I run 8 production
> clusters of various sizes, one is 300 GB just for data and fail over takes
> about 30 seconds. Is 30 seconds to slow? If so then using a database
> mirror would be the way to go. You will need to ensure that the client is
> using ADO.NET 2.0 so that your failover is supported. However, there will
> be no need to handle the failover as there is when using TAF on RAC.
> Having said that currently SQL server has no RAC equivalency for scaling
> out. If this is a requirement I would go with a HP Itanium system such as
> the 6840 this would allow you to scale up over time rather than scaling
> out.
> Let me know if you need clarification
> John Vandervliet.
>
> "Jim" <ilmm555@.yahoo.com> wrote in message
> news:uimO$QJhHHA.4980@.TK2MSFTNGP02.phx.gbl...
>
|||We run a combination most the instances are active/passive setups, howerver
we have 3 clusters that each of 2 instances of SQL. the servers are exact
matches of each other and can handle the load for both instances when needed.
"Hassan" wrote:

> Do you run 8 production clusters where all of them are single instance
> cluster..i.e one active and one passive or do you have a multi instance
> cluster say more than 2 active nodes with 1 passive node for any of the
> active nodes to failover.
>
> "John Vandervliet" <jvandervliet@.SJRB.AD> wrote in message
> news:7FE2AB87-4B70-44A0-8400-85B209FC6626@.microsoft.com...
>
>
|||On Apr 26, 5:12 pm, John Vandervliet
<JohnVandervl...@.discussions.microsoft.com> wrote:
> We run a combination most the instances are active/passive setups, howerver
> we have 3 clusters that each of 2 instances of SQL. the servers are exact
> matches of each other and can handle the load for both instances when needed.
>
> "Hassan" wrote:
>
>
>
>
>
> - Show quoted text -
Hassan,
My employer SteelEye Technology has a solution called LifeKeeper for
SQL Server. With our solution we can cluster 2-nodes locally with
either shared storage or syncronous host based replication and also
support a 3rd node in the DR site with either sync or async
replication. Of course sync replication will impact performance if
done across a WAN, but it is the only way to guarantee no data loss.
Failover time is similar to MSCS, so if that is too long, you will
have to look elsewhere.
Here is some information.
www.steeleye.com/pdf/literature/lifekeeper_for_sql_server.pdf
David A. Bermingham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com

2012年3月22日星期四

Anyone deployed stretch clustering ?

2012年3月6日星期二

any other plugin algorithm developed?

2012年2月16日星期四

Any equivalent to Oracle RAC available for SQL Server?

Sql ANSI Padding

Blog Archive

About Me