It is important to use the right tool for the right job. DB replication, of one flavor or another, is usually the most sound approach for a hot backup server.
A data warehouse is usually the most sound approach for reporting. This entails setting up some type of ETL, normalizing the data, performing the necessary conversions and translations, among other things, but is very effective at building a reporting scheme. Exceptions to this occur when you use some type of reporting component that relies on an AR layer. DSO is usually the most sound approach for allowing Remedy applications of separate purposes to share share data, setting up geographically disparate active/active system. Axton Grams The opinions, statements, and/or suggested courses of action expressed in this E-mail do not necessarily reflect those of BMC Software, Inc. My voluntary participation in this forum is not intended to convey a role as a spokesperson, liaison or public relations representative for BMC Software, Inc. On Mon, May 17, 2010 at 11:53 AM, William Abdo < william.a...@contractor.verio.net> wrote: > I have a simple question Dan, > > I am not being critical here either I just was wondering: > > Why did you not go with mirroring of the DB solution? > > > > > > Respectfully, > > > > William Abdo > > > > From: Action Request System discussion list(ARSList) > [mailto:arsl...@arslist.org] On Behalf Of Wangler, Dan > Sent: Monday, May 17, 2010 10:51 AM > To: arslist@ARSLIST.ORG > Subject: DSO > > > > ** > > Dear List > > > > We are trying to implement a database replication by using DSO. We have a > duplicate, parallel system to our production that is used for > Analytics/reporting. We have setup DSO to push changes, as they occur, from > the production (source) server to the parallel (target) server. Our > thoughts were to use the target server both for reporting and as a hot > backup. We have all workflow and escalations turned on but are sending > transaction to the target server as Data Only. I wanted to check to see if > anyone is doing this, using DSO to push to a reporting, and to solicit > comments about this approach. > > > > I see one important issue. When a record is created or modified on the > source server, the record always says it was modified last by “Distributed > Server”. This is probably because DSO pushes the transaction to the target > server and returns a “Successful” transfer back to the source server. Is > there anyway to retain the “real” last modified by and last Modified Date? > While the information on the target server is correct, it is confusing to > the user on the source server. In addition, while DSO is updating fields > with the successful status, another user could have open the form and get > the message saying the ticket had already been updated by someone else since > the user opened it. Is there someway to prevent this from happening? > > > > Another issue we see is that as information is pushed from the source server > to the target server, filters are driven on the target server. In some > cases, modifications on one form causes an update to a different form and > could lead to permissions issues. Is there someway to stop this without > adding to the filter qualification “USER’ != “Distributed Server”? One way, > I can think of, is placing the target server in Admin Only mode. Would the > DSO creates and updates take place in Admin Only? > > > > Any comments or suggestions would be greatly appreciated. > > > > Regards > > Dan > > > > Dan Wangler, SAIC; MHS Remedy Support Team > > Tri-Service Infrastructure Management Program Office (TIMPO) > > 300 Convent St, Suite 1800; San Antonio, Texas, 78205 > > Phone: 210-338-3162; Email: dan.wangler....@timpo.osd.mil > > > > _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
