Thanks Sylvain for the feed back! It is interesting that you called it
Utility because I was also thinking about calling the DB Utilities.
That is one of the things I am wondering about; will putting the views and
tables used by AR System in the Utilities DB have much impact on
performance. I tend to think it will not have too much impact since it is
all on the same DB server, same disk volume, etc. But then again I am not
a DBA, network engineer or storage engineer :)
Here is scenario where I would like for custom views to be in their own DB
space. Our convention is to prefix our custom views with "uv_" for User
View ("ut_" for User Table). We also like to name our View forms with the
View name they use. For example we have a view called "uv_LAWItems" and
the View Form name is "LAW:uv_LAWItems". The AR maintained view of the
View Form is "LAW_uv_LAWItems". There have been times where I was a little
confused around the difference between uv_LAWItems and LAW_uv_LAWItems
(usually late at night under some kind of time restriction). Now maybe our
naming conventions could use some tweaking? However moving uv_LAWItems to
a different DB would make it more clear which is the custom object and
which is the AR maintain object referencing the custom object in another DB.
The performance implication is one of the things I am the most curious
about and hoping some of our DB gurus will chime in.
I just realized I didn't include our specs in my initial post. I am
working mostly with theory here so I am hoping the specs are not
that relevant but here they are:
ARS 7.6.04 SP3
ITSM .7.6.04 SP2
AR Server - Windows 2008 Standard 64-bit
DB Server Windows 2008 Enterprise 64-bit
DBMS - MS SQL 2008 Standard 64-bit
Jason
On Fri, Sep 7, 2012 at 12:05 AM, Sylvain YVON <sylvain.y...@gmail.com>wrote:
> We did that here on Oracle for a custom 7.5 app with one ARSystem and
> one Utility schemas. The utility schema contains all the temporary
> tables, procedures and packages for maintenance and imports (of users,
> entities, ...). This is very handy because this is all temporary stuff
> that we can afford to loose and restore a week old backup, not like AR
> System data that is so expensive to replicate.
> That said, we chose to create the views and materialized views needed
> by ARS workflow inside the AR System schema simply because we don't
> see a value add in using the utility schema. I mean, if you create
> views, you will probably create a view form in AR System anyway. If
> you use a View Form based on a complexe view, that uses the data
> contained in your AR System tables, are you sure that storing the view
> in a separate schema/DB doesn't add an overhead (like authentication,
> network loop, etc) ? I don't have the answer, maybe it depends on the
> DB engine you use ?
>
> Sylvain
>
> On Fri, Sep 7, 2012 at 2:40 AM, Easter, David <david_eas...@bmc.com>
> wrote:
> > **
> >
> > Just thinking somewhat inside the box – but wouldn’t overlays do the
> > majority of this for you? Any custom objects you create would be well
> > known/documented as would any modifications to BMC base objects. The
> base
> > BMC objects would remain on the system unchanged. If you really then
> wanted
> > to transfer only your extensions and modifications to a new box, you’d
> just
> > transfer the custom and overlaid objects.
> >
> >
> >
> > -David J. Easter
> >
> > Manager of Product Management, AR System
> >
> > BSM & Atrium Solutions Management
> >
> > BMC Software, Inc.
> >
> >
> >
> > 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.
> >
> >
> >
> > From: Action Request System discussion list(ARSList)
> > [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
> > Sent: Wednesday, September 05, 2012 3:33 PM
> > To: arslist@ARSLIST.ORG
> > Subject: Thoughts regarding a separate DB for custom DB objects
> >
> >
> >
> > **
> >
> > I would like to get some input on something I have been thinking about
> > recently. I am considering creating a new DB on the same DB server as
> the
> > ARSystem DB. This DB would be right next to the ARSystem DB but would
> house
> > all of the custom DB work we do. My thought is to have all custom
> tables,
> > views, stored procedures, functions, etc. in new DB which would ideally
> > leave everything in the ARSystem DB created, maintained and modified via
> the
> > AR System API or BMC installers. Basically I am picturing a layer of
> > abstraction or a library of custom objects if you will. Maybe more like
> a
> > different namespace or data set for those CMDB gurus out there.
> >
> >
> >
> > As it is right now in our very customized 7.5 ARS DB all custom tables,
> > views, etc. are all intermixed with the ARS maintained objects. We try to
> > keep our objects lumped together by naming convention but just when my
> team
> > starts using the same convention a different DBA (for example) comes
> along
> > and uses their favorite convention. If we all agree to only make
> changes to
> > the custom DB then naming convention is not as important (DBAs usually
> ask
> > which DB do you need something not so much “what is your naming
> > convention?”).
> >
> >
> >
> > Another considerations is portability of the ARSystem DB. Right now
> when we
> > refresh our production DB to another environment there are things like
> > different linked server references that need to be updated, object
> owners,
> > etc. All objects in the custom DB would have the same names between
> > environments (Dev, QA, Prod). With all of the custom objects in their
> own
> > DB we can move ARSystem DBs between environments and as long as the
> custom
> > DB is configured correctly for the environment no changes are needed to
> any
> > of ARSystem DB objects.
> >
> >
> >
> > Our new “out of the box” ITSM 7.6.04 system does not have any custom DB
> work
> > done yet but I know it is only a matter of time before the need arises
> as we
> > transition between old and new systems. If there are advantages and no
> > major negative results to this architecture I would like to set this up
> > while we are still out of the box.
> >
> >
> >
> > Can anybody think of any negative (or positive) effects of this
> approach? I
> > am figuring because it still on the same DB server that there should not
> be
> > much performance impact.
> >
> >
> >
> > Thanks!
> >
> > Jason
> >
> > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
> >
> > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
