Transaction Logging in D3

Assume current D3
Assume current Linux (rh)

I would like to get some feedback on the use of transaction logging in
D3. Does anyone use D3's transaction logging and is there any (how
much) drag on the system? We would be implementing this on one of our
busiest files so this is very important.

Are there other tools for logging available that work better/faster?

Thanks

On Aug 19, 8:59*am, dtsig wrote:
> Assume current D3
> Assume current Linux (rh)
>
> I would like to get some feedback on the use of transaction logging in
> D3. *Does anyone use D3's transaction logging and is there any (how
> much) drag on the system? *We would be implementing this on one of our
> busiest files so this is very important.
>
> Are there other tools for logging available that work better/faster?
>
> Thanks

Are you talking transaction logging as in moving data to a hot backup
server, or are you talking about transaction bracketing as in ensuring
all updates get done or none get done?

Dale

On Aug 19, 11:08*am, dbenedic...@gmail.com wrote:
> On Aug 19, 8:59*am, dtsig wrote:
>
> > Assume current D3
> > Assume current Linux (rh)
>
> > I would like to get some feedback on the use of transaction logging in
> > D3. *Does anyone use D3's transaction logging and is there any (how
> > much) drag on the system? *We would be implementing this on one of our
> > busiest files so this is very important.
>
> > Are there other tools for logging available that work better/faster?
>
> > Thanks
>
> Are you talking transaction logging as in moving data to a hot backup
> server, or are you talking about transaction bracketing as in ensuring
> all updates get done or none get done?
>
> Dale

I am talking about 'transaction logging' as used in PICK D3. Simply
writting to another device.

As opposed to that pesky SQL 'transaction control'

Thanks

A robust transaction logging or data replication solution is typically
much more involved than "simply writing to another device", and
"Better" is a very subjective measure :-)

You might want to check out our Visage.DRS product
http://www.stamina.com.au/Visage/visageDRS.htm

Some "features" that I believe make Visage.DRS a more appropriate
solution in many situations include :

* ability to replicate transactions to multiple secondary or
replicated servers, so you can have a hot standby onsite AND a full
Disaster Recovery machine far, far away in case of events like fire,
and it doesn't have to stop there (but usually does :-)

* we can build a "clean" replicated server from a "dirty" backup. In
other words, if you are running 24/7 and simply don't have a time
window that allows you to get a clean backup (ie: no data changed
whilst the backup was being generated = no verification errors), how
DO you get to create your initial replication image? Visage.DRS CAN
create a system that is fully synched with a live/primary server, even
though it was initially "seeded" from a backup of a system that was in
a state of flux

* The actual PHYSICAL data projection & replication takes place
OUTSIDE of the D3 database environment, so the database only has to do
"data-basey" things (anyone had the "joy" of playing with D3 socket
interfaces)

* set & forget, doesn't consume phantoms on the primary server, or
require ongoing administration & close management once configured, and
provides pro-active email alerts for any issues that may arise

* BECAUSE the transaction logs are outside of the D3 database, they
don't consume space or contribute to overflow fragmentation

* Visage.DRS will automatically "self heal" & recover from things
like network outages, say a VPN dropping a connection to a remote
site. With Visage.DRS, not only can you get an email sent alerting you
to the fact that the VPN link is down, but when it comes back up
(could be router-based & require no operator intervention) data will
automatically start to "flow" again to the affected system(s)

* even if a secondary/replicated server is "down", transactions can
still be transported off the primary system for safety & security

* you can actually USE your replicated servers to do useful work,
typically reporting, reducing load on your primary system

* even with replicated systems, some people want/need the security of
a verified backup on offline media --> but if your backup takes 20
hours to complete, this can be "challenging". With Visage.DRS you can
simply stop transaction log updates on a secondary system, perform a
"clean" backup, then restart log processing

* Visage.DRS works with D3/NT!! (I don't believe the "native" TL
product does)

* as well as "simple" DR replication, Visage.DRS can also be used for
multi-site "consolidations" (eg: head office accumulating information
from satellite branches/warehouses/stores)


Replicated/secondary servers don't need the special "Hot Backup"
licence offered by TL, but rather need a single "real" user for each
account that is being protected/replicated. In the event of a
disaster, then you would simply activate your "real" licence on a
replicated server in exactly the same way that you would if you rushed
in replacement hardware


Whilst Visage.DRS is currently only offered on D3, the technology
COULD be applied to all of the mv environments, and we are happy to
discuss options with people that can see some features listed above
that may be lacking in their current DR solution

HTH


Ross Ferris
Stamina Software
Visage > Better by Design!

On Aug 19, 5:45*pm, Ross Ferris wrote:
> A robust transaction logging or data replication solution is typically
> much more involved than "simply writing to another device", and
> "Better" is a very subjective measure :-)
>
> You might want to check out our Visage.DRS producthttp://www.stamina.com.au/Visage/visageDRS.htm
>
> Some "features" that I believe make Visage.DRS a more appropriate
> solution in many situations include :
>
> * ability to replicate transactions to multiple secondary or
> replicated servers, so you can have a hot standby onsite AND a full
> Disaster Recovery machine far, far away in case of events like fire,
> and it doesn't have to stop there (but usually does :-)
>
> * we can build a "clean" replicated server from a "dirty" backup. In
> other words, if you are running 24/7 and simply don't have a time
> window that allows you to get a clean backup (ie: no data changed
> whilst the backup was being generated = no verification errors), how
> DO you get to create your initial replication image? Visage.DRS CAN
> create a system that is fully synched with a live/primary server, even
> though it was initially "seeded" from a backup of a system that was in
> a state of flux
>
> * The actual PHYSICAL data projection & replication takes place
> OUTSIDE of the D3 database environment, so the database only has to do
> "data-basey" things (anyone had the "joy" of playing with D3 socket
> interfaces)
>
> * set & forget, doesn't consume phantoms on the primary server, or
> require ongoing administration & close management once configured, and
> provides pro-active email alerts for any issues that may arise
>
> * BECAUSE the transaction logs are outside of the D3 database, they
> don't consume space or contribute to overflow fragmentation
>
> * *Visage.DRS will automatically "self heal" & recover from things
> like network outages, say a VPN dropping a connection to a remote
> site. With Visage.DRS, not only can you get an email sent alerting you
> to the fact that the VPN link is down, but when it comes back up
> (could be router-based & require no operator intervention) data will
> automatically start to "flow" again to the affected system(s)
>
> * even if a secondary/replicated server is "down", transactions can
> still be transported off the primary system for safety & security
>
> * you can actually USE your replicated servers to do useful work,
> typically reporting, reducing load on your primary system
>
> * *even with replicated systems, some people want/need the security of
> a verified backup on offline media --> but if your backup takes 20
> hours to complete, this can be "challenging". With Visage.DRS you can
> simply stop transaction log updates on a secondary system, perform a
> "clean" backup, then restart log processing
>
> * Visage.DRS works with D3/NT!! (I don't believe the "native" TL
> product does)
>
> * as well as "simple" DR replication, Visage.DRS can also be used for
> multi-site "consolidations" (eg: head office accumulating information
> from satellite branches/warehouses/stores)
>
> Replicated/secondary servers don't need the special "Hot Backup"
> licence offered by TL, but rather need a single "real" user for each
> account that is being protected/replicated. In the event of a
> disaster, then you would simply activate your "real" licence on a
> replicated server in exactly the same way that you would if you rushed
> in replacement hardware
>
> Whilst Visage.DRS is currently only offered on D3, the technology
> COULD be applied to all of the mv environments, and we are happy to
> discuss options with people that can see some features listed above
> that may be lacking in their current DR solution
>
> HTH
>
> Ross Ferris
> Stamina Software
> Visage > Better by Design!

Thanks man .. we will review.