Thursday, 5 July 2007

How to get an Oracle DBA job

In just 48 hours, 120 resumes from Oracle DBAs landed on the desk of Debbie Reames, a senior technical recruiter for Los Angeles-based staffing company Commercial Programming Systems. So Reames did what a lot of recruiters do. She wiped out half the pile in a three-step process. Need an H-1B visa? Gone. Need to relocate? Not for this job. Only worked at small companies? This job might be too big for you.

Despite the steepest downturn in the history of IT, there are jobs to be had by Oracle certified professionals and DBAs, according to many surveys. Of course, there are also longer lists of qualified candidates. When it comes to searching for a job in this market, even the most experienced IT pros need to remember some of the rules they learned long ago and apply some new strategies as well.

In many ways, the DBA market can be divided into two groups – juniors and seniors.

The junior DBAs, those with less than three years of experience, are the ones facing layoffs and a meaner job market, according to Don Burleson, owner of Kittrell, N.C.-based BEI Oracle Consulting. Burleson is the author of 17 books related to Oracle technology and careers, including Conducting the Oracle Job Interview, a guide for IT managers who have to assess Oracle job candidates.

"Many companies will not hire beginners, period," Burleson said.

However, Burleson said, there is hope for junior DBAs. Companies that are not willing to spend $120,000 annually for a seasoned professional will sometimes take rookies and train them. Burleson suggested the health care industry and universities as two places that new DBAs should look for that critical first job.
Government security clearance key for veterans

Then there are the veterans. DBAs who have more than 10 years of experience, who hold advanced degrees and who have specialized skills are still in strong demand.

Knowledge of Oracle financials, SAP, PeopleSoft, RAC, iAS and Unix are qualities that carry weight, Burleson said. Also, government security clearance is something that gets many Oracle DBAs past the first round of resume cuts. In addition, development skills such as Java, Windows, J2EE and portals lend candidates a competitive advantage.

More important, Reames said, a candidate's skill set has to match a company's needs. "They really need to have every skill," Reames said.

"If the job calls for someone with data modeling," she said, "and I don't see any specific data modeling experience, I'll discount it."

In addition to specific technical skills, Burleson says, many companies are looking at educational backgrounds, preferring to hire candidates who have graduate degrees or MBAs. Companies value DBAs who have an understanding of finance or accounting, the business processes that DBAs support.
Follow-up calls, first-round interviews

For both groups, there are some basic ground rules to getting through the critical first round of interviews.

Simply getting the resume in as early as possible can help. With 120 to read, Reames might not see each of them before she finds enough qualified candidates to interview.

Candidates should call recruiters too see whether their resume was received, she said. "Don't be afraid to call to follow up," Reames said. "It may give you an advantage, and we may not have looked at the resume otherwise."

Applicants who make the first cut are usually interviewed on the telephone. It's important to remember that the person conducting the interview may not have a technical background, Burleson said. At this point, candidates are being judged on their non-technical qualities. Communication skills are crucial here, experts say.

Because communication skills are so critical on the job, Burleson recommended that candidates provide potential employers with writing samples, preferably ones that have been published. Several online sites, accept submissions of technical tips, he pointed out.
Real techie talk

The handful of applicants who survive the telephone interview can expect an interview at the job site and what Burleson calls the "teching" of the candidate. He advises interviewers to ask specific questions, such as "What is the default password for the sys user in Oracle?"

There's no faking answers to those questions, and an interviewer can easily judge the technical skills of the candidates. "Only a practicing DBA knows the answer is 'change_on_install,'" Burleson said. "A seasoned DBA can spot a faker instantly."

Then comes the last stage, on-site meetings with a company's IT staff. These meetings typically last about half a day, and this is where the potential hires will really be tested. Sometimes there are open-ended questions, such as "What would be the first thing you would do if an end user complains that performance is poor?" The answers to these questions can be very revealing, Burleson said, because they don't have one right answer, and they show how candidates can think on their feet, or how innovative a DBA is.

Perhaps more important, this final interaction is where the intangibles, like interpersonal skills, are judged. Having a DBA who is a team player is a priority for most, if not all, companies. In many cases, the intangibles make the difference.

"I've seen companies reject the most technically qualified candidate. It happens all the time," Burleson points out. "DBAs have to be able to play well with others."

Finally, Burleson said, forget casual Fridays.

"It's the kiss of death to underdress for an interview," he said.

"Appearance does count."
For more information, consult Don Burleson's book Conducting the Oracle Job Interview

Finding and killing locked sessions

Because of Oracle internal locking, there are times when it is useful to be able to locate and kill Oracle sessions that are locking database resources.
The LockedSessions.sql script, which applies to all Oracle versions, can be run to locate sessions that are holding locked resources.

Wednesday, 4 July 2007

How to unlock an Unix account?

As root, run
passwd -u username
You can lock an account with
passwd -l username

Linux Password & Shadow File Formats

Traditional Unix systems keep user account information, including one-way encrypted passwords, in a text file called /etc/passwd. As this file is used by many tools (such as "ls'') to display file ownerships, etc. by matching user id #'s with the user's names, the file needs to be world-readable. Consequentally, this can be somewhat of a security risk.

Another method of storing account information, one that I always use, is with the shadow password format. As with the traditional method, this method stores account information in the /etc/passwd file in a compatible format. However, the password is stored as a single "x" character (ie. not actually stored in this file). A second file, called /etc/shadow, contains encrypted password as well as other information such as account or password expiration values, etc. The /etc/shadow file is readable only by the root account and is therefore less of a security risk.

While some other Linux distributions forces you to install the Shadow Password Suite in order to use the shadow format, Red Hat makes it simple. To switch between the two formats, type (as root):

/usr/sbin/pwconv
To convert to the shadow format
/usr/sbin/pwunconv
To convert back to the traditional format

With shadow passwords, the /etc/passwd file contains account information, and looks like this:

smithj:x:561:561:Joe Smith:/home/smithj:/bin/bash

Each field in a passwd entry is separated with ":" colon characters, and are as follows:

● Username, up to 8 characters. Case-sensitive, usually all lowercase
● An "x" in the password field. Passwords are stored in the /etc/shadow file.
● Numeric user id. This is assigned by the adduser script. Unix uses this field, plus the following group field, to identify which files belong to the user.
● Numeric group id. Red Hat uses group id's in a fairly unique manner for enhanced file security. Usually the group id will match the user id.
● Full name of user. I'm not sure what the maximum length for this field is, but try to keep it reasonable (under 30 characters).
● User's home directory. Usually /home/username (eg. /home/smithj). All user's personal files, web pages, mail forwarding, etc. will be stored here.
● User's "shell account". Often set to /bin/bash to provide access to the bash shell.

Perhaps you do not wish to provide shell accounts for your users. You could create a script file called /bin/sorrysh, for example, that would display some kind of error message and log the user off, and then set this script as their default shell.

Note: If the account needs to provide "FTP" transfers to update web pages, etc. then the shell account will need to be set to /bin/bash -- and then special permissions will need to be set up in the user's home directory to prevent shell logins.

The /etc/shadow file contains password and account expiration information for users, and looks like this:

smithj:Ep6mckrOLChF.:10063:0:99999:7:::

As with the passwd file, each field in the shadow file is also separated with ":" colon characters, and are as follows:

● Username, up to 8 characters. Case-sensitive, usually all lowercase. A direct match to the username in the /etc/passwd file.
● Password, 13 character encrypted. A blank entry (eg. ::) indicates a password is not required to log in (usually a bad idea), and a ``*'' entry (eg. :*:) indicates the account has been disabled.
● The number of days (since January 1, 1970) since the password was last changed.
● The number of days before password may be changed (0 indicates it may be changed at any time)
● The number of days after which password must be changed (99999 indicates user can keep his or her password unchanged for many, many years)
● The number of days to warn user of an expiring password (7 for a full week)
● The number of days after password expires that account is disabled
● The number of days since January 1, 1970 that an account has been disabled
● A reserved field for possible future use

How do Unix file permissions work?

Unix file permissions are based upon an octal code. Unix file permissions are stored in a ten character array. The first character of the file permissions stores the file type. The standard file types are:
The next nine characters are divided into three groups of three characters, each of which represents a different role on the system:
● User permissions govern what a user can do with his own files.
● Group permissions govern what another user on the same system, in the user group to which the file belongs, can do with the file.
● Other permissions govern what any other user on the same system can do with the file.

The three sets of three characters represent the permissions to the file for each role. The three permissions which may be granted to each role are:
Read permission grants the ability to view the contents of the file.
Write permission grants the ability to save changes to the contents of the file.
eXecute permission grants to ability to execute the file. This is useful for programs and shell scripts.

A Unix File Permissions Example

A sample set of file permissions:
-rw-rw-r-- 1 will staff file-permissions.shtml

The file permissions for this file are:
Role Permissions
User rw-
Group rw-
Other r--

This means that the user, or a member of the "web" group, can Read or Write this file. Any other user on the system can Read this file.
Unix File Permissions SUID and SGID Bits
File permissions are also used to make a program or shell script SUID (Set User ID) or SGID (Set Group ID). If a file is SUID, it will run with the privileges of the files owner, instead of the privileges of the person running the program. If a file is SGID, it will run with the privileges of the files group owner, instead of the privileges of the person running the program.
SUID and SGID programs are used to enable normal system users to accomplish tasks which would otherwise require privileged access.

The `passwd` program allows users to change their passwords. This requires the ability to write to the /etc/passwd file (and most often the shadowed password file), which unprivileged users should not normally have.

The file permissions of /usr/bin/passwd are:
-r-sr-xr-x 2 root wheel /usr/bin/passwd

The 's' in the space normally occupied by the first 'x' signifies that this file is SUID. No matter who executes this program, it will always run with the privileges of the user root.

Expressing Unix File Permissions in Octal
Unix file permissions are sometimes expressed in octal notation. r is equal to the value 4, w is equal to the value 2, and x is equal to the value 1.
Mathematically, rwx equals 7, because 4+2+1=7. Similarly, rw- is equal to 6 and r-x is equal to 5.

Setting Unix File Permissions

Unix file permissions are set using the `chmod` program. `chmod 644` will set a files permissions to -rw-r--r--.
Source:
Tech FAQ

What Is a DBA?

Every organization using a database management system (DBMS) to manage data requires a database administration group to ensure the effective use and deployment of the company’s databases. Since most modern organizations of any size use a DBMS, the need for a database administrator (DBA) is greater today than ever before. However, the discipline of database administration is neither well understood nor universally practiced in a coherent and easily replicated manner.
An oft-repeated story about database administration underscores both the necessity for database administration and the lack of understanding of a DBA’s function. It goes something like this:
● The CIO of Acme Corporation hires a management consulting company to streamline their information technology (IT) operations. The consultant, determined to understand the way Acme works, begins by interviewing the CIO. One of his first questions is: “So, I see that you have a DBA on staff. What does he do?”
● The CIO replies, “Well, I’m told that we need the DBA to make sure our Oracle databases stay online. I know that some of our critical business processes like order entry and inventory use Oracle, but I really don’t know what the DBA does. But please don’t tell me I need another one, because we can barely afford to pay the one we have!”
This is a sad but too often true commentary on the state of database administration in many organizations. DBMS software is so complex these days that very few people understand more than just the basics (like SQL). However, DBAs understand the complexities of the DBMS, making them a valuable resource. Indeed, sometimes the only source of database management and development knowledge within the organization is the DBA.
The DBA, often respected as a database guru, is just as frequently criticized as a curmudgeon with vast technical knowledge but limited people skills. Just about every database programmer has his or her favorite DBA story. You know, those anecdotes that begin with “I had a problem...” and end with “and then he told me to stop bothering him and read the manual.” DBAs simply do not have a “warm and fuzzy” image. However, this perception probably has more to do with the nature and scope of the job than with anything else. The DBMS spans the enterprise, effectively placing the DBA on call for the applications of the entire organization. The truth is, many database problems require periods of quiet reflection and analysis for the DBA to resolve. Therefore, DBAs generally do not like to be disturbed. However, due to the vast knowledge most DBAs possess (the guru, again), their quiet time is usually less than quiet; constant interruptions to answer questions and solve problems is a daily fact of life.
DBAs, more than most, need to acquire exceptional communication skills. Data is the lifeblood of computerized applications. Application programs are developed to read and write data, analyze data, move data, perform calculations using data, modify data, and so on. Without data, there would be nothing for the programs to do. The DBA is at the center of the development life cycle—ensuring that application programs have efficient, accurate access to the corporation’s data. As such, DBAs frequently interface with many different types of people: technicians, programmers, end users, customers, and executives. However, many DBAs are so caught up in the minutiae of the inner workings of the DBMS that they never develop the skills required to relate appropriately to their coworkers and customers.
However, we have not yet answered the question: What is a DBA? The short answer is simple: A DBA is the information technician responsible for ensuring the ongoing operational functionality and efficiency of an organization’s databases and the applications that access those databases.
From Craig Mullins'
Database Administration: The Complete Guide to Practices and Procedures, Addison Wesley Professional; ISBN: 0201741296; 1st edition (June 14, 2002).