Optimize IT

2 Posts authored by: Daniel Lanzi
Share: |


If you’re a BMC Database Automation (BDA) user, you’ve already discovered the efficiencies and cost savings that come from automated provisioning and patching of your databases. However, there are probably lots of other database administration tasks you need to perform frequently, such as creating backups or setting up user accounts, that could be made easier and more efficient.

To help you automate these kinds of tasks, BDA includes an incredibly useful feature called Custom Actions. A Custom Action allows you to execute administrative tasks on a target server in the context of BDA’s knowledge of the database environment and includes a rich set of support features.

Custom Actions are script-based, run on Linux, UNIX and Windows, and can contain pretty much any content you like. For example, if your action installs an agent on a server, you can include the agent installer package as part of the action’s content. BDA also provides a useful set of environment variables for your action to use, including things like the Oracle home and SID of the target, patch levels, the install user, and many others.

You can run your actions on one or more nodes, and you can schedule them to be run in the future or on a recurring basis. You can also create a menu option for your action in the BDA user interface so that users run it from the BDA Grid just like provisioning, and, like provisioning, it can have its own pre-verification phase.



Because Custom Actions are subject to BDA’s Role-Based Access Controls (RBAC), you can tightly control who runs your action and where it runs. You can limit your action to specific domains, operating system types, database versions and more.


As an added bonus, you can insert your action into a provisioning workflow as a pre or post-script, guaranteeing that it gets run whenever someone provisions a database.


Try automating a few of your favorite DBA tasks with Custom Actions and you’ll quickly see how it can make your workday more efficient.

Share: |

I’ve been a hockey fan as long as I can remember. Growing up on the frozen shores of Lake Ontario, nearly every kid laced up the skates and hit the ice at an early age. In my hometown we even had a pretty good minor league team to cheer on.


avery.jpgContrary to popular belief, there’s a lot more to the game than guys chasing a rubber disk and taking the occasional whack at it (and each other) with a stick. There are all kinds of strategies employed by teams to create a competitive advantage. One of these strategies is the use of Role Players. There are lots of roles that players take on based on their particular skills and the needs of the team. These include Scorers, Checkers, Penalty Killers, and the ever-popular Enforcers (shown at left).


Roles are equally important in Service Automation. By understanding the specific needs of users in the different organizations and functions in your business, you can setup your Service Automation tools to accommodate business needs without creating excessive risk and bringing on undue scrutiny from the security team.


In BMC Database Automation, Role-Based Access Control (RBAC) provides a lot of flexibility when setting up the security model for your users. Let’s look at a few basics.


In BDA, you create a User for each individual that will be logging into the system. It goes without saying that each person should be given their own user account – sharing should be highly discouraged.


Users are organized into Groups; each group is granted a Role on one or more domains. Roles are simply sets of BDA capabilities. There are many different capabilities in BDA, including things like “Apply an Oracle Patch”, “Provision a SQL Server Instance”, “Create a Template” and so on. In all, there are more than seventy individual capabilities in BDA. Some of the possible relationships in the RBAC model are illustrated below.


RBAC Picture.jpg


For example, you could create a role called Operations and define it with the capabilities “Oracle Provisioning”, “Oracle Patch Apply”, and “Oracle Patch Rollback”. You then create user wgretzky, assign him to group OraDBAs, and grant OraDBAs the Operations role on domain “/Production”. Our friend Mr. Gretzky (holder of 61 NHL records, by the way) can then perform his provisioning and patching tasks on Oracle databases in the /Production domain without the ability to change (or even see) databases in other domains.

There are a few interesting things to note in this model:

  • Users can be members of more than one group
  • A group can be granted different roles on different domains
  • A group can be granted the same role on different domains
  • A group can be granted multiple roles on one domain. When this happens, the group’s capabilities for that domain are simply the union of the capabilities in each role
  • Granting a role on a parent domain will grant access to all of the parent’s subdomains, both current and future.


For hockey fans and non-fans alike, the BDA RBAC model affords tremendous flexibility in setting up security for your users. With careful planning, you can leverage this flexibility to organize your user community in a way that meets your organizations’ security requirements.

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.