DBA Sensation

December 19, 2008

how to use dbms_stats package in a efficient way

Filed under: [System Performance tuning] — zhefeng @ 4:31 pm

i found a very good doc talking about oracle dbms_stats package from dba-oracle website: here is the link (http://www.dba-oracle.com/oracle_tips_dbms_stats1.htm)

The old fashioned “analyze table” and dbms_utility methods for generating CBO statistics are obsolete and somewhat dangerous to SQL performance. This is because the cost-based SQL Optimizer (CBO) relies on the quality of the statistics to choose the best execution plan for all SQL statements. The dbms_stats utility does a far better job in estimating statistics, especially for large partitioned tables, and the better stats results in faster SQL execution plans.

Let’s see how dbms_stats works. It’s easy! Here is a sample execution of dbms_stats with the options clause:
exec dbms_stats.gather_schema_stats( –
ownname => ‘SCOTT’, –
estimate_percent => dbms_stats.auto_sample_size, –
method_opt => ‘for all columns size repeat’, –
degree => 34 –
)

When the options clause is specified you may specify GATHER options. When GATHER AUTO is specified, the only additional valid parameters are ownname, stattab, statid, objlist and statown; all other parameter settings are ignored.
exec dbms_stats.gather_schema_stats( –
ownname => ‘SCOTT’, –
options => ‘GATHER AUTO’
)

There are several values for the options parameter that we need to know about:

*gather – re-analyzes the whole schema.

*gather empty – Only analyze tables that have no existing statistics.

*gather stale – Only re-analyze tables with more than 10% modifications (inserts, updates, deletes).

*gather auto – This will re-analyze objects which currently have no statistics and objects with stale statistics. (like “gather empty”+”gather stale”)

Note that both gather stale and gather auto require monitoring. If you issue the “alter table xxx monitoring” command, Oracle tracks changed tables with the dba_tab_modifications view. Below we see that the exact number of inserts, updates and deletes are tracked since the last analysis of statistics.
SQL> desc dba_tab_modifications;

Name Type
——————————–
TABLE_OWNER VARCHAR2(30)
TABLE_NAME VARCHAR2(30)
PARTITION_NAME VARCHAR2(30)
SUBPARTITION_NAME VARCHAR2(30)
INSERTS NUMBER
UPDATES NUMBER
DELETES NUMBER
TIMESTAMP DATE
TRUNCATED VARCHAR2(3)

The most interesting of these options is the gather stale option. Because all statistics will become stale quickly in a robust OLTP database, we must remember the rule for gather stale is > 10% row change (based on num_rows at statistics collection time).

Hence, almost every table except read-only tables will be re-analyzed with the gather stale option. Hence, the gather stale option is best for systems that are largely read-only. For example, if only 5% of the database tables get significant updates, then only 5% of the tables will be re-analyzed with the “gather stale” option.

The CASCADE option

When analyzing specific tables, the cascade option can be used to analyze all related objects based on foreign-key constraints. For example, stats$snapshot has foreign key referential integrity into all subordinate tables (stats$sysstat, etc.), so a single analyze can invoke an analyze of all subordinate tables:

exec dbms_stats.gather_table_stats( –
ownname => ‘PERFSTAT’, –
tabname => ’STATS$SNAPSHOT’ –
estimate_percent => dbms_stats.auto_sample_size, –
method_opt => ‘for all columns size skewonly’, –
cascade => true, –
degree => 7 –
)

The DEGREE Option

Note that you can also parallelize the collection of statistics because the CBO does full-table and full-index scans. When you set degree=x, Oracle will invoke parallel query slave processes to speed up table access. Degree is usually about equal to the number of CPUs, minus 1 (for the OPQ query coordinator).
Automating sample size with dbms_stats

Now that we see how the dbms_stats options works, get see how to specify the sample size for dbms_stats. The following estimate_percent argument is a new way to allow Oracle’s dbms_stats to automatically estimate the “best” percentage of a segment to sample when gathering statistics:

estimate_percent => dbms_stats.auto_sample_size

You can verify the accuracy of the automatic statistics sampling by looking at the dba_tables sample_size column. It is interesting to note that Oracle chooses between 5% to 20% for a sample_size when using automatic sampling.

In our next installment we will look at automatics the collection of histogram data from dbms_stats.

December 17, 2008

How to Run a DTS Package as a Scheduled Job

Filed under: 3. MS SQL Server — zhefeng @ 10:52 am

SUMMARY
A problem that you might frequently encounter with a Data Transformation Servic…
A problem that you might frequently encounter with a Data Transformation Services (DTS) package is that the DTS package runs error-free from the SQL Server Enterprise Manager, but the DTS package fails when it is scheduled to run as a job. Usually, this occurs because of a difference in the security context when the package is run as a job versus when the package is run interactively.

This article explains the security issues involved in running DTS packages.

Some Terms Description
———————-
DTS: Data Transformation Services
SQL authentication: A security system that is based on Microsoft SQL Server logins and passwords.
Standard security: See SQL authentication.
SQL Server authentication: See SQL authentication.
Microsoft Windows NT authentication: When a user connects through a Microsoft Windows user account, SQL Server verifies that the account name and password were validated when the user logged on to a computer running Microsoft Windows NT, Microsoft Windows 2000, Microsoft Windows 95 or Microsoft Windows 98.
Integrated security: See Microsoft Windows NT authentication.
Windows NT or Microsoft Windows 2000 authentication: See Microsoft Windows NT authentication.
Microsoft Windows NT account or login equals Windows login or account: Same as Microsoft Windows NT login account or Microsoft Windows 2000 login account.
SQL Agent: SQL Server Agent Service
SEM: SQL Server Enterprise Manager

#1. Where is the DTS Package Running?
One problem that is frequently reported about DTS packages is the difference in behavior when a package is run from the SQL Enterprise Manager versus when the DTS package is scheduled as a job. When you run the package from the DTS Designer in SQL Enterprise Manager (SEM), the package is running on the computer where you are seated. If you are at the server (either physically, or through remote access software), the package is run on the server. If you are seated at a workstation and you have registered the SQL Server server in Enterprise Manager, then the package is run on the workstation. The security context of the package is that of the Windows NT account you used to log in to that computer. When the package is run as a scheduled job, the package is always run on the server.

Frequently, a developer creates and tests the DTS package interactively on their workstation through the DTS Designer in Enterprise Manager. After the DTS package is debugged, the package is then scheduled as a job. This changes the location of the package from the developer’s workstation to the server. If the package was loading text data into SQL Server, the package fails unless the text file and the path to the file exist on the server. If the package was connecting to another server, the package fails if the security context of the job does not support the connection.
Who Owns the Job That Runs the DTS Package?
Packages are scheduled by creating a job that is managed by the SQL Agent service. This job, as any other scheduled job, has an owner. The owner can be either a SQL Server login or a Windows NT account.

To determine the owner:

* Double-click the job in Enterprise Manager and then look at the Owner drop-down combo box.

-or-

* Run the msdb.dbo.sp_help_job system stored procedure.

SQL Server 2000

The security context in which the job is run is determined by the owner of the job. If the job is owned by a login that is not a member of the Sysadmin server role, then the package is run under the context of the account setup as the SQL Agent Proxy Account, and has the rights and permissions of that account.

For SQL Agent Proxy to be able to run jobs that connect to SQL Server, the SQL Agent Proxy account must have proper Windows/NT permissions and be granted login access to SQL Server with appropriate database permissions. For the jobs that execute a DTS package, the SQL Agent Proxy Account must have read and write permissions to the temp directory of the Account the SQL Server Agent is running under. For example,
c:\Documents and Settings\\Local Settings\Temp
If the job is owned by an account (either a SQL Server login or a Windows NT authenticated login) that is a member of the Sysadmin role, the SQL Agent job runs under the context of the account used to start the SQL Agent service.

Also, if the job is owned by a Windows NT domain account and if the package is stored in the SQL Server or SQL Server repository (not as a file), you must start the SQL Server service by using an account from the same domain or an account from a trusted domain. For example, if the SQL Agent job is owned by an account from the USA domain, then the account used to start the SQL Server service must be either from the USA domain or a domain trusted by the USA domain. If the SQL Server is started using a local account, the package fails to run.

#2. What Determines the Owner?
Question: When you right-click the DTS package and you choose to schedule the package, how is the owner assigned?

Answer: The owner of the SQL Agent job depends on how the SQL Server is registered in the Enterprise Manager. If the SQL Server is registered using a Windows NT authentication, the owner of the scheduled job is the account used to start the SQL Agent service. If the SQL Server is registered in SEM using SQL Server authentication (for example, the SA login), the owner of the job is that same SQL Server login.

To change the ownership of the package:

1. Double-click the job in Enterprise Manager.
2. Click the General tab, and then click the Owner drop-down combo box.

You can also use the msdb.dbo.sp_update_job system stored procedure to change the ownership of the package.

#3. How is the DTS Package Launched?
If you manually run a package by using the DTSRun.exe command line utility, the security context is that of the Windows account you used to log in to the computer. If you run the package by using DTSrun.exe through the xp_cmdshell extended stored procedure, the package is run in the context of the account used to start the SQL Server service, provided that the user that executed xp_cmdshell is a member of the Sysadmin role. If the user that executed xp_cmdshell is not an account in the Sysadmin role, then DTSRun.exe runs in the context of the SQLAgentCmdExec account.

If the SQL Server was started using the Local System account, the DTS package has no permissions outside of the computer that is running SQL Server.

If the SQL Server service is started under a Windows NT account, the package has the same rights and permissions as that Windows NT account. If that Windows NT account is a local machine account (as opposed to a domain account), the package does not have any rights outside of that computer. If the Windows NT account is a domain account, the package may be able to access resources on many different computers on that domain.
How are Windows NT-authenticated Connections Made?
Sometimes a DTS package contains an object that makes a connection to a data source using Windows NT authentication. The security context used for this connection is the same as the context of the package that is running. If the package is run from a command prompt by using DTSRun.exe, the credentials of the currently logged-in Windows NT account is used. If the package is run as a SQL Server Agent job, then the integrated security connection is made using the account you used to start SQL Agent (assuming that the owner of the package is a member of the Sysadmin role).

#4. Common Problems
Here are a few other common problems you might encounter when you run DTS packages as scheduled jobs in SQL Agent:

1). OS level Security permission error (this is the most common error for DTS job, most users failed on this)
Error:
Executed as user: xxx\yyy. The process could not be created for step 1 of job 0xE04DF638883CED43BC09B920B39D43A4 (reason: A required privilege is not held by the client). The step failed.
I was searching on the internet and ms kb for a quite long for finding this “required privilege”. Unfortunately microsoft failed to mention this. After a 3-hour call with MS support Engineer, finally i got the solution:
The proxy account as well as the SQL Server startup account have to be enabled on these security policies in Local Security Policy(use “secpol.msc” to get interface, it’s in “security settings”->”local policies”->”user rights assignment” ):
1. Act as part of the Operating System
2. Log on as a service (SeServiceLogonRight)
3. Log on as a batch job (SeBatchLogonRight)
4. Replace a process-level token (SeAssignPrimaryTokenPrivilege)
5. Bypass traverse checking (SeChangeNotifyPrivilege)
6. Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)
After that, restart sql agent service and you’re done!

2). Mapped Drives
If the package relies on the physical location of a file designated by a mapped drive letter, the package may fail when it is run as a scheduled SQL Agent job, regardless of who owns the package. SQL Agent is a Windows NT service and Windows NT services cannot see mapped drive letters. The mapping is part of the user’s profile that is loaded when a user logs on to a Windows NT session. Services do not work with user profiles. Use a UNC path instead of a mapped drive letter. For additional information about why a service cannot use a mapped drive, click the following article number to view the article in the Microsoft Knowledge Base:
180362 (http://support.microsoft.com/kb/180362/ ) INFO: Services and redirected drives

3). Relative Path
A relative path (or drive letter) is specific to the current location of the package (like C:\). If a package is designed on a workstation and is then scheduled, the location from which the package is run changes. The drive letter paths now reference a different physical location, that of the server. Unless the referenced files are also moved to the server, the package execution fails.

4). COM Components in ActiveX Scripts
If COM components (for example, calls to Microsoft ActiveX Data Objects (ADO), Remote Data Objects (RDO), or Decision Support Object (DSO) objects) are called in an ActiveX script, the called components must exist on the computer from which the DTS package is being run. If you run the package from the DTS Designer in SEM or DTSRun.exe, the components must exist on the computer at which you are seated. If the package is scheduled to be run by SQL Agent, the called components must be loaded on the computer hosting the SQL Server.

5). Package Security
DTS packages can have owner passwords and user passwords. These passwords affect who can edit and run the packages. Neither of these affect the security context in which the package is run.

6). SQLAgentCmdExec Permissions
If the job is executed under the context of the SQLAgentCmdExec account, and the SQLAgentCmdExec account does not have login rights to the SQL Server, the job may fail with the following error message:
DTSRun: Loading… DTSRun: Executing… DTSRun OnStart: DTSStep_DTSExecuteSQLTask_1 DTSRun OnError: DTSStep_DTSExecuteSQLTask_1, Error = -2147217843 (80040E4D) Error string: Login failed for user ‘NT_name\SQLAgentCmdExec’. Error source: Microsoft OLE DB Provider for SQL Server Help file: Help context: 0 Error Detail Records: Error: -2147217843 (80040E4D); Provider Error: 18456 (4818) Error string: Login failed for user ‘NT_name\SQLAgentCmdExec’. Error source: Microsoft OLE DB Provider for SQL Server Help file: Help context: 0 DTSRun OnFinish: DTSStep_DTSExecuteSQLTask_1 DTSRun: Package execution complete. Process Exit Code 1. The step failed.

MS KB Link:
http://support.microsoft.com/kb/269074
http://support.microsoft.com/kb/918760

December 11, 2008

How to set trace for others sessions, for your own session and at instance level

Filed under: [System Performance tuning] — zhefeng @ 10:32 am

This is a very good detailed article about oracle tracing. The original links is here:
http://www.petefinnigan.com/ramblings/how_to_set_trace.htm

Tools to analyse trace files

Up to and including Oracle 10g the tool that is generally used to analyse trace files is called tkprof. This tool formats the trace files that have been generated into a more readable format. Understanding the trace file format seems daunting on first inspection. A good source for details on the trace file format is a metalink note 39817.1. In 10g there is a new tool for formatting trace files called trcsess. This tool has been designed to deal with the new trace facilities that allow trace to be identified based on client identifier or by a combination of service name / module / action. This allows trace to be completed even if connection pooling and multi-threading is used. An individual client in these circumstances could share many different sessions.

Find out where the trace file will be written to

If the user you are using is not a DBA or to be more specific has not been granted access to the data dictionary view V$PARAMETER then you will need to use this technique to find out where your trace files are written to:

SQL> set serveroutput on size 1000000 for wra
SQL> declare
2 paramname varchar2(256);
3 integerval binary_integer;
4 stringval varchar2(256);
5 paramtype binary_integer;
6 begin
7 paramtype:=dbms_utility.get_parameter_value(‘user_dump_dest’,integerval,stringval);
8 if paramtype=1 then
9 dbms_output.put_line(stringval);
10 else
11 dbms_output.put_line(integerval);
12 end if;
13 end;
14 /
C:\oracle\admin\sans\udump

PL/SQL procedure successfully completed.

SQL>

If the user you are using has access to the base views then you can do the following instead.

SQL> select name,value
2 from v$parameter
3 where name=’user_dump_dest’;

NAME
—————————————————————-
VALUE
——————————————————————————–
user_dump_dest
C:\oracle\admin\sans\udump

SQL>

Making trace files available

There is an undocumented parameter _trace_files_public that if set to true changes the file permissions in the user_dump_dest directory when trace files are created to allow everyone to read them. This parameter can be checked with the following SQL. Beware that this is an undocumented parameter and should not be routinely set to true as some information in trace files can be used by hackers or malicious users. You can set this parameter by adding the following line to the init.ora file:

# allow trace files to be created with public permissions
_trace_files_public=true
# disable this feature:
#_trace_files_public=true
# or =>
_trace_files_public=false

Here is the SQL to check the value of this parameter:

SQL> select x.ksppinm name,y.ksppstvl value
2 from sys.x$ksppi x,sys.x$ksppcv y
3 where x.inst_id=userenv(‘Instance’)
4 and y.inst_id=userenv(‘Instance’)
5 and x.indx=y.indx
6 and x.ksppinm=’_trace_files_public’;

NAME
—————————————————————-
VALUE
——————————————————————————–
_trace_files_public
FALSE

SQL>

Let’s start with some examples of how to check trace for another session that is connected to the database.

Now find the SID and SERIAL# of the other session

We are using a simple example and the session we are looking for is for the user SCOTT and we are logged into this session with AS SYSDBA. We need to be logged in as SYS or AS SYSDBA so that we can access the packages DBMS_SUPPORT and DBMS_SYSTEM needed to set trace in another session or in our own session. Again as with the first example about access to v$parameter a user with access to the views V$SESSION and V$PROCESS is needed. First lets find the SID and SERIAL#

SQL> connect system/manager@sans as sysdba
Connected.
SQL> col sid for 999999
SQL> col serial# for 999999
SQL> col username for a20
SQL> col osuser for a20
SQL> select s.sid,s.serial#,s.username,s.osuser
2 from v$session s,v$process p
3 where s.paddr=p.addr;

SID SERIAL# USERNAME OSUSER
——- ——- ——————– ——————–
1 1 SYSTEM
2 1 SYSTEM
3 1 SYSTEM
4 1 SYSTEM
5 1 SYSTEM
6 1 SYSTEM
7 1 SYSTEM
8 1 SYSTEM
9 253 SYSTEM ZULIA\pete
10 20 SCOTT ZULIA\pete

10 rows selected.

SQL>

great the SID and SERIAL# that we need are 10 and 20.

A word about trace levels

Before we use the DBMS_SYSTEM package to set trace in SCOTT’s session we need to discuss what levels are. Trace in fact sets an event in the Oracle kernel (what is an event? – An event is simply a flag to the Oracle kernel to tell it to emit some trace messages or to add some additional processing or to activate some new functionality. Some events are used by support analysts and developers to force certain conditions to occur for testing purposes). In our case we want to look at event number 10046 – This event tells the Oracle kernel to emit trace lines and timings. The levels available in Oracle through some of the interfaces used to set trace are:

* Level 0 = No statistics generated
* Level 1 = standard trace output including parsing, executes and fetches plus more.
* Level 2 = Same as level 1.
* Level 4 = Same as level 1 but includes bind information
* Level 8 = Same as level 1 but includes wait’s information
* Level 12 = Same as level 1 but includes binds and waits

For a complete list of events that can be set look at the file $ORACLE_HOME/rdmbs/mesg/oraus.msg on Unix or Linux. This file is not shipped on Windows systems. Also setting any event other that trace (10046) should not be done without the guidance of Oracle support.

Set trace in another session using DBMS_SYSTEM

First lets set trace in SCOTT’s session using the DBMS_SYSTEM package. Before we do let’s turn on timed statistics so that the trace files get timing info and also set the dump file size so that there is plenty of room for the trace being generated.

SQL> exec dbms_system.set_bool_param_in_session(10,20,’timed_statistics’,true);

PL/SQL procedure successfully completed.

SQL> exec dbms_system.set_int_param_in_session(10,20,’max_dump_file_size’,2147483647);

PL/SQL procedure successfully completed.

OK, here we set trace in SCOTT’s session

SQL> — now use standard dbms_support interface
SQL> exec dbms_system.set_sql_trace_in_session(10,20,true);

PL/SQL procedure successfully completed.

SQL> — execute some code
SQL> exec dbms_system.set_sql_trace_in_session(10,20,false);

PL/SQL procedure successfully completed.

SQL>

A second way to set trace in another session – This time setting trace level as well

Next we can again use the DBMS_SYSTEM interface but this time use the set event syntax. This allows us to set any event in the database. This is of course not sanctioned by Oracle support and can cause damage to your database if not done correctly. Use this interface with care and just set 10046 (trace) events. Here is how it is done:

SQL> exec dbms_system.set_ev(10,20,10046,8,”);

PL/SQL procedure successfully completed.

SQL> — execute some code
SQL> exec dbms_system.set_ev(10,20,10046,0,”);

PL/SQL procedure successfully completed.

Installing the DBMS_SUPPORT package

Using the example above we set trace to level 8, you can of course set it to any level you wish from the list we discussed above. Next we will use the DBMS_SUPPORT package to set trace. This package is not installed by default and is in fact undocumented and indeed on some platforms and versions its not even shipped and you will need to talk to Oracle support and get it from metalink. First we will install the package:

SQL> — now do the same with dbms_support
SQL> — the package has to be installed first – you should ask Oracle first though!
SQL> @%ORACLE_HOME%\rdbms\admin\dbmssupp.sql

Package created.

Package body created.

SQL>

Use DBMS_SUPPORT to set trace in another users session

Next use the interface to again set trace for SCOTT’s session that we found earlier. here it is:

SQL> exec dbms_support.start_trace_in_session(10,20,waits=>true,binds=>false);

PL/SQL procedure successfully completed.

SQL> — execute some code
SQL> exec dbms_support.stop_trace_in_session(10,20);

PL/SQL procedure successfully completed.

SQL>

use DBMS_SUPPORT to set trace in your own session

OK, that’s how to set trace in SCOTT’s session. How do we set trace in our own session. Well first we can use all of the approaches seen above and pass in the SID and SERIAL# for our own session. There are other methods for setting trace in your own session though. The first is again using the DBMS_SUPPORT package. Here it is:

SQL> exec dbms_support.start_trace(waits=>true,binds=>false);

PL/SQL procedure successfully completed.

SQL> — run some code
SQL> exec dbms_support.stop_trace;

PL/SQL procedure successfully completed.

SQL>

Use DBMS_SESSION to set trace in your own session

The next method for setting trace in our own session also is done using a built in package, this time DBMS_SESSION. here it is:

SQL> — in your own session using dbms_session
SQL> exec dbms_session.set_sql_trace(true);

PL/SQL procedure successfully completed.

SQL> — execut some code
SQL> exec dbms_session.set_sql_trace(false);

PL/SQL procedure successfully completed.

SQL>

using oradebug to set trace through SQL*Plus

oradebug is a debugging utility that is essentially undocumented and is intended for use by Oracle support analysts for various tasks one of which is that it can be used to set trace. oradebug is available from svrmgrl before Oracle 9i and from SQL*Plus after. The first step in using this tool is to find the OS PID or the Oracle PID of the process you want to analyse. You can do this as follows:

SQL> connect system/manager@sans as sysdba
Connected.
SQL> col sid for 999999
SQL> col serial# for 999999
SQL> col spid for a8
SQL> col username for a20
SQL> col osuser for a20
1 select s.sid,s.serial#,p.spid,p.pid,s.username,s.osuser
2 from v$session s,v$process p
3* where s.paddr=p.addr
SQL> /

SID SERIAL# SPID PID USERNAME OSUSER
——- ——- ——– ———- ——————– ——————–
1 1 2528 2 SYSTEM
2 1 2536 3 SYSTEM
3 1 2540 4 SYSTEM
4 1 2544 5 SYSTEM
5 1 2552 6 SYSTEM
6 1 2604 7 SYSTEM
7 1 2612 8 SYSTEM
8 1 2652 9 SYSTEM
10 343 3740 12 SYS ZULIA\pete
12 70 864 13 SCOTT ZULIA\pete

10 rows selected.

Now that we have found the Operating System PID and Oracle PID (values 864 and 13 in this case) of SCOTT’s session we can use this to set trace with the oradebug tool as follows:

SQL> — set the OS PID
SQL> oradebug setospid 864
Windows thread id: 864, image: ORACLE.EXE
SQL> — or set the Oracle pid
SQL> oradebug setorapid 13
Windows thread id: 864, image: ORACLE.EXE
SQL> — set the trace file size to unlimitd
SQL> oradebug unlimit
Statement processed.
SQL> — now turn on trace for SCOTT
SQL> oradebug event 10046 trace name context forever, level 12
Statement processed.
SQL> — run some queries in another session and then turn trace off
SQL> oradebug event 10046 trace name context off
Statement processed.

Some things to be aware of

You should be aware that some of these methods allow setting of extended trace and some do not. Those that allow extended trace are easy to spot. These methods include ways to set the trace level or include variables suitably named such as waits or binds which again enable extended trace facilities. Some trace methods have a default level such as set sql_trace=true which sets trace to level 8. The rest set trace to normal trace levels.

One other point to note is that we have looked first at ways to set trace in another session to the one you are logged into and also now at ways of setting trace in your own session, there is a third option, which is to set trace for the whole system (i.e for all users sessions), This is not recommended unless you know what you are doing and are monitoring trace as you can quickly fill the file system.

Setting trace at the instance level using the init.ora

Trace can be set in the database initialization file the init.ora file. If you use spfile then you can still use the init.ora file and then copy it to the spfile. Simply add the following line to the init.ora file:

sql_trace=true

You can also set timed_statistics and max_dump_file_size in the init.ora file in the same way. i.e

timed_statistics=true
max_dump_file_size=unlimited

Trace can also be disabled at the instance level by simply commenting out the same parameter or by deleting it. A commented line is shown next:

#sql_trace=true

Or you can set the same parameter to false:

sql_trace=false

A second instance level method – setting events

Another method that can be used to set trace at the instance level is to add an event (or multiple events)to the initialization file, the init.ora as described above. Again if you use spfile’s then you can copy the init.ora to spfile or use ALTER SYSTEM to set the value in the spfile. Here is an example of setting the trace event 10046 to level 12 in the initialization file:

# set the event in the init.ora
event = “10046 trace name context forever, level 12”
# to turn off the event simply comment out the line as follows:
# event = “10046 trace name context forever, level 12”

Using ALTER SESSION to set trace in your own session

The alter session command can be used to set trace for the current session as follows:

SQL> alter session set sql_trace=true;

Session altered.

SQL> — execute some code
SQL> alter session set sql_trace=false;

Session altered.

SQL>

This method can also be used to set timing and dump file size for the current session as follows:

SQL> alter session set timed_statistics=true;

Session altered.

SQL> alter session set max_dump_file_size=unlimited;

Session altered.

SQL>

Using ALTER SESSION to set extended trace using events

One last method I want to demonstrate is the alter session syntax to set events. Again stick to 10046 (trace) and do not attempt to set any of the other events that are available without Oracles say so in a supported system. Here is the example of setting trace to level 12, including binds and waits:

SQL> alter session set events ‘10046 trace name context forever, level 12’;

Session altered.

SQL> — execute some code
SQL> alter session set events ‘10046 trace name context off’;

Session altered.

SQL>

A sample logon trigger to set trace

Quite often you would like trace to be set for a session as soon as the user logs on. Also you may want to be able to set trace for a specific set of users when they log in. This can easily be done with a database logon trigger. Here is a sample trigger.

Connected to:
Personal Oracle9i Release 9.2.0.1.0 – Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 – Production

SQL> create or replace trigger set_trace after logon on database
2 begin
3 if user not in (‘SYS’,’SYSTEM’) then
4 execute immediate ‘alter session set timed_statistics=true’;
5 execute immediate ‘alter session set max_dump_file_size=unlimited’;
6 execute immediate ‘alter session set sql_trace=true’;
7 end if;
8 exception
9 when others then
10 null;
11 end;
12 /

Trigger created.

SQL> sho errors
No errors.
SQL>

OK, that was easy. You can also use the alter session set events ‘10046 trace name context forever,level 12’ syntax if you prefer You can also enable other checks within the trigger if need by using any valid PL/SQL logic that you prefer. One tip is that if you have any troubles with your system trigger and it causes logins to fail is to always include, as I have, an exception handler that calls null; for any error condition. If all else fails you can disable system triggers by setting the parameter _system_trig_enabled=false in the initialisation file. This undocumented / hidden parameter stops the processing of system triggers such as logon triggers.

Using ALTER SYSTEM to set trace at the instance level

Finally you can also use the alter system syntax to set trace at the system level. Here is a simple example:

SQL> alter system set sql_trace=true scope=spfile;

System altered.

SQL>
SQL> — to turn it off again do:
SQL> alter system set sql_trace=false scope=spfile

System altered.

SQL>

Checking the privileges of the packages used to set trace

Some of the packages used in this example have to be run as SYS or you need to be logged in AS SYSDBA or specific privileges need to be granted against those packages for the user that will run them. The default privileges for DBMS_SYSTEM, DBMS_SUPPORT and for DBMS_SESSION are showed next in output from who_can_access.sql (A script that shows privileges hierarchically for an object who’s name is passed in). Here they are:

— check who has access to dbms_system
who_can_access: Release 1.0.0.0.0 – Production on Fri Feb 27 12:53:24 2004
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.

get user input

NAME OF OBJECT TO CHECK [USER_OBJECTS]: dbms_system
OWNER OF THE OBJECT TO CHECK [USER]: sys
OUTPUT METHOD Screen/File [S]:
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [/tmp]:

Checking object => SYS.DBMS_SYSTEM
====================================================================

Object type is => PACKAGE (TAB)
Privilege => EXECUTE is granted to =>
Role => OEM_MONITOR which is granted to =>
User => SYS

PL/SQL procedure successfully completed.

For updates please visit http://www.petefinnigan.com/tools.htm

SQL>

— check who has access to dbms_support
who_can_access: Release 1.0.0.0.0 – Production on Fri Feb 27 12:54:29 2004
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.

get user input

NAME OF OBJECT TO CHECK [USER_OBJECTS]: dbms_support
OWNER OF THE OBJECT TO CHECK [USER]: sys
OUTPUT METHOD Screen/File [S]:
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [/tmp]:

Checking object => SYS.DBMS_SUPPORT
====================================================================

PL/SQL procedure successfully completed.

For updates please visit http://www.petefinnigan.com/tools.htm

SQL>

— check who has access to dbms_session
who_can_access: Release 1.0.0.0.0 – Production on Fri Feb 27 12:55:31 2004
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.

get user input

NAME OF OBJECT TO CHECK [USER_OBJECTS]: dbms_session
OWNER OF THE OBJECT TO CHECK [USER]: sys
OUTPUT METHOD Screen/File [S]:
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [/tmp]:

Checking object => SYS.DBMS_SESSION
====================================================================

Object type is => PACKAGE (TAB)
Privilege => EXECUTE is granted to =>
Role => PUBLIC

PL/SQL procedure successfully completed.

For updates please visit http://www.petefinnigan.com/tools.htm

SQL>

That’s it, there are many ways to set trace in your session, in others sessions and at system level. Also many ways to enable extended trace. Beware of the privileges needed to run some of them and beware of setting events explicitly.

New tracing methods in Oracle 10g – DBMS_MONITOR

Oracle 10g offers a new package to allow sessions to be traced end to end in multi-tier architectures that share sessions using connection pooling or multi-threading. This package allows applications written using for instance JDBC / Java or something like Forte to be traced where it would normally be very difficult to identify a database session belonging to a client as the sessions / clients pairings change with time.

The new functionality works in three levels. You can use the old SID / SERIAL# pairings to identify a session but you can also use a client identifier or a service name / module / action to identify a client session to be traced. The package also offers a set of procedures to allow statistics to be gathered for the same groups. These statistics can then be selected from dynamic views.

let’s now take a look at some of the features of this package.

Setting trace with DBMS_MONITOR using SID / SERIAL#

Trace can be set for the current user session, for the current session or for another users session. First lets look at tracing another users session. First we need to get the SID and SERIAL# – we will use SCOTT connected through SQL*Plus as our sample session:

SQL> select s.sid,s.serial#,s.username
2 from v$session s, v$process p
3 where s.paddr=p.addr
SQL> /


SID SERIAL# USERNAME
———- ———- ——————————
248 153 SCOTT
258 61 DBSNMP
251 418 SYSMAN
255 961 SYS
249 215

27 rows selected.

SQL>

OK as with previous methods we can use a SID / SERIAL# pair of 248 and 153. lets set trace for this user session:

SQL> exec dbms_monitor.session_trace_enable(248,153,TRUE,FALSE);

PL/SQL procedure successfully completed.

SQL> — execute some sql
SQL> — in the other session
SQL> — turn trace off
SQL> exec dbms_monitor.session_trace_disable(248,153);

PL/SQL procedure successfully completed.

SQL>

Setting trace at the session level using DBMS_MONITOR

The same procedures can be used to set trace for the session by omitting the serial#. This is demonstrated next:

SQL> exec dbms_monitor.session_trace_enable(248);

PL/SQL procedure successfully completed.

SQL> — execute some sql in the other session
SQL> — turn off trace
SQL> exec dbms_monitor.session_trace_disable(248);

PL/SQL procedure successfully completed.

SQL> — or you can turn it on with
SQL> exec dbms_monitor.session_trace_enable(248,null);

PL/SQL procedure successfully completed.

SQL> — turn off again with:
SQL> exec dbms_monitor.session_trace_disable(248,null);

PL/SQL procedure successfully completed.

SQL>

Setting trace for the current session using DBMS_MONITOR

Setting trace for the current user session is done by leaving out the SID and SERIAL# altogether by setting them to NULL. Here is an example:

SQL> — trace the current session
SQL> exec dbms_monitor.session_trace_enable(null,null);

PL/SQL procedure successfully completed.

SQL> — execute some code
SQL> — turn it off again
SQL> exec dbms_monitor.session_trace_disable(null,null);

PL/SQL procedure successfully completed.

SQL> — to get waits and binds do
SQL> exec dbms_monitor.session_trace_enable(null,null,true,true);

PL/SQL procedure successfully completed.

SQL> — execute some code
SQL> — then turn off tracec
SQL> exec dbms_monitor.session_trace_disable(null,null);

PL/SQL procedure successfully completed.

SQL> — or turn it on like this
SQL> exec dbms_monitor.session_trace_enable();

PL/SQL procedure successfully completed.

SQL> — execute some SQL and then turn off trace
SQL> exec dbms_monitor.session_trace_disable();

PL/SQL procedure successfully completed.

SQL>

That completes some of the ways to use DBMS_MONITOR to set trace using SID, SERIAL#, or at the session level or for the current session.

Set trace using a client identifier

Tracing using the client identifier allows trace to be set across multiple sessions as many Oracle shadow processes can work on behalf of one client. Also trace is persistent across all instances and restarts. First we need to see how the client identifier is set. This can be done using the DBMS_SESSION package as follows:

SQL> exec dbms_session.set_identifier(‘pete id’);

PL/SQL procedure successfully completed.

SQL>

We can check now for a specific identifier in the V$SESSION view with the client_identifier column.

SQL> select s.username,s.client_identifier
2 from v$session s,v$process p
3 where s.paddr=p.addr
4 and client_identifier is not null;

USERNAME
——————————
CLIENT_IDENTIFIER
—————————————————————-
SCOTT
pete id

SQL>

OK, now we can use this information to set trace for this client identifier as follows:

SQL> exec dbms_monitor.client_id_trace_enable(‘pete id’,true,false);

PL/SQL procedure successfully completed.

SQL> — wait for the client session to do something
SQL> — turn off trace as follows:
SQL> exec dbms_monitor.client_id_trace_disable(‘pete id’);

PL/SQL procedure successfully completed.

SQL>

That was quite easy!. next let’s look at setting trace at the service, module action levels.

Setting trace for service/module/action with DBMS_MONITOR

This method of setting trace acts hierarchically. The first level is that trace is set globally for the whole database (all instances) You can override this by setting an instance name in the call to turn on trace. For this example as I am on a single instance database I will leave this parameter at its default. There are three levels to the hierarchy. If we set ACTION to NULL then all actions for the module and service are traced. The next level, if we set MODULE to NULL then all actions for all modules for the specified service name are traced. The trace will be collected into multiple trace files and the new tool trcsess must be used to collate all the trace files into one usable file.

The service name can be set using the package DBMS_SERVICE and the procedure CREATE_SERVICE. Here is an example:

SQL> exec dbms_service.create_service(‘Test Service’,’test network’);

PL/SQL procedure successfully completed.

SQL> — it can be deleted with
SQL> exec dbms_service.delete_service(‘Test Service’);

PL/SQL procedure successfully completed.

SQL>

The service name can quite often be set already by the tool. It could be used to group together a set of programs / modules that perform some business task. Next let’s see how the module and actions can be set.

SQL> — set action
SQL> exec dbms_application_info.set_action(‘PAYMENT’);

PL/SQL procedure successfully completed.

SQL> — set the module
SQL> exec dbms_application_info.set_module(‘ACCOUNTS’,’PAYMENT’);

PL/SQL procedure successfully completed.

SQL>

To view the relevant service names, modules and actions for sessions in the database you can use the v$SESSION view as follows:

SQL> col service_name for a15 wrapped
SQL> col username for a15 wrapped
SQL> col module for a15 wrapped
SQL> col action for a15 wrapped
SQL> select s.username,s.service_name,s.module,s.action
2 from v$session s,v$process p
3 where s.paddr=p.addr;

USERNAME SERVICE_NAME MODULE ACTION
————— ————— ————— —————
SYSMAN SANS
SYSMAN SANS OEM.SystemPool
DBSNMP SYS$USERS emagent@emil (T
NS V1-V3)

DBSNMP SYS$USERS emagent@emil (T
NS V1-V3)

SYS$USERS
SYS SANS ACCOUNTS PAYMENT
SCOTT SANS SQL*Plus

29 rows selected.

SQL>

As we deleted our sample service name set up with DBMS_SERVICE.CREATE_SERVICE we will just use the default value SANS inserted by Oracle in our test case. Let’s test some of the methods of setting trace with this functionality.

SQL> — set trace for all modules and actions for SANS service name
SQL> exec dbms_monitor.serv_mod_act_trace_enable(‘SANS’,DBMS_MONITOR.ALL_MODULES,DBMS_MONITOR.ALL_ACTIONS,TRUE,FALSE,NULL);

PL/SQL procedure successfully completed.

SQL> — turn it off
SQL> exec dbms_monitor.serv_mod_act_trace_disable(‘SANS’);

PL/SQL procedure successfully completed.

SQL> — now trace all actions for service SANS and module accounts
SQL> exec dbms_monitor.serv_mod_act_trace_enable(‘SANS’,’ACCOUNTS’,DBMS_MONITOR.ALL_ACTIONS,TRUE,FALSE,NULL);

PL/SQL procedure successfully completed.

SQL> — now turn it off
SQL> exec dbms_monitor.serv_mod_act_trace_disable(‘SANS’,’ACCOUNTS’);

PL/SQL procedure successfully completed.

SQL> — finally test service SANS, module ACCOUNTS and action PAYMENT
SQL> exec dbms_monitor.serv_mod_act_trace_enable(‘SANS’,’ACCOUNTS’,’PAYMENT’,TRUE,FALSE,NULL);

PL/SQL procedure successfully completed.

SQL> — turn it off
SQL> exec dbms_monitor.serv_mod_act_trace_disable(‘SANS’,’ACCOUNTS’,’PAYMENT’);

PL/SQL procedure successfully completed.

SQL> — you can turn on or off binds and waits as well or use the waits=>true
SQL> — syntax instead.
SQL>

OK, that wraps up the new procedures in 10g that can be used to turn on trace in different ways to capture true end to end trace for multi-tier applications. You should also be aware that DBMS_MONITOR also provides procedures to enable statistic gathering at the same levels of client identifier and service name/module/action. These statistics are stored and can then be accessed by selecting from V$SERV_MOD_ACT_STATS and V$CLIENT_STATS views. I will not detail those procedures here as this short paper is concentrating on trace only.

One last idea – use AUTOTRACE in SQL*Plus

OK, one final way to set and get trace, is to use the SQL*Plus AUTOTRACE facilities. There are a few settings that you can use. These are as follows:

* set autotrace off – The default – no output
* set autotrace on explain – This shows only the optimizer path
* set autotrace on statistics – This only shows SQL statistics
* set autotrace on – Includes both of the above
* set autotrace traceonly – As above but the query output is not displayed

One more final item – CBO trace 10053

One other event that you might like to try and experiment with is the 10053 event. This event traces the Cost Based Optimizer (CBO) and shows all of the plans and costs assigned to them that it tried in its search for the best cost and also is shows how it came to its decision. The 10053 event has two levels 1 and 2. More detail is emitted if level 1 is used rather than level 2. The output is again sent to a trace file in the directory specified by user_dump_dest. The trace is only generated if the SQL is hard parsed and also obviously uses the CBO. To get a trace file you can use any of the methods above that allow the event number to be specified. An example is:

SQL> alter session set events ‘10053 trace name context forever, level 1

Session altered.

SQL> — execute some SQL to create a CBO trace.
SQL> — turn CBO trace off
SQL> alter session set events ‘10053 trace name context off’;

Session altered.

SQL>

An excellent document describing how to interpret CBO trace files called “A Look under the Hood of CBO – the 10053 Event.pdf” has been written by Wolfgang Breitling of Centrex Consulting Corporation. The URL for Wolfgangs site is http://www.centrexcc.com/papers.html

Adds-on:
About 10046 tracing
10046 has 4 tracing levels
1 – Standard SQL_TRACE, the same as sql_trace
4 – Level 1 + bind values
8 – Level 1 + wait events
12 – Level 1 + Level 4 + Level 8
Like sql_trace,10046 can be set on system level or session level
1. system level
Add the parameter in:
event=”10046 trace name context forever,level 12″

2. session level
SQL> alter session set events ‘10046 trace name context forever’;
SQL> alter session set events ‘10046 trace name context forever, level 8’;
SQL> alter session set events ‘10046 trace name context off’;

Note: for finding the crossing trace file for current session, use this query to get the location:
select d.value||’/’||lower(rtrim(i.instance, chr(0)))||’_ora_’||p.spid||’.trc’ trace_file_name
from
( select p.spid
from v$mystat m,v$session s,v$process p
where m.statistic# = 1 and s.sid = m.sid and p.addr = s.paddr) p,
( select t.instance from v$thread t,v$parameter v
where v.name = ‘thread’ and (v.value = 0 or t.thread# = to_number(v.value))) i,
( select value from v$parameter where name = ‘user_dump_dest’) d;

Using import (imp) or data pump import (impdp) to import a table without data results in the table’s statistics being locked in 10gR2

Filed under: [System Performance tuning] — zhefeng @ 9:03 am

when you import the table without data by using impdp, the statistics was locked after importing. Whatever you re-gather the statistics, the statistics won’t change and it won’t give your the locked error even.

The solution are varied from serveral way:
1. Gather the statistics with force=true
exec dbms_stats.unlock_schema_stats(ownname => 'WORLDDB9_REP', force => TRUE);

2. unlock the statistics using DBMS_STATS.UNLOCK_[SCHEMA|TABLE]_STATS, then gather statistics on the table using DBMS_STATS.GATHER_[SCHEMA|TABLE|INDEX]_STATS
EXEC DBMS_STATS.UNLOCK_TABLE_STATS(ownname => 'WORLDDB9_REP', tabname => 'TRIGGER_BASED');
exec dbms_stats.unlock_schema_stats(ownname => 'WORLDDB9_REP');

3. To prevent import (imp) from locking the table’s statistics when importing a table without the rows (rows=n), use statistics=none. To prevent data pump import (impdp) from locking the table’s statistics when importing a table without the rows (content=metadata_only), use exclude=(table_statistics,index_statistics).

Metalink: Note:433240.1

December 10, 2008

Find Long running queries in SQL2005

Filed under: 3. MS SQL Server — zhefeng @ 2:27 pm

The following query shows you the long running queries in the database by combination of few dynamic management views. It’s quite useful to get the “bottleneck” on-the-fly when your system is super busy.

Select dmText.text as 'Executed Query',dmStats.last_execution_time as 'Last Executed Time', dmstats.*
from
sys.dm_exec_query_stats as dmStats
Cross apply
sys.dm_exec_sql_text(dmStats.sql_handle) as dmText
Order By
total_elapsed_time desc,
dmStats.last_execution_time desc

December 8, 2008

Oracle RAC-stop crs autostart on one node

Filed under: [RAC] — zhefeng @ 12:24 pm

***Background:
One of the RAC node vanpgprodb05 always has some system level issue and every time when we reboot the machine the crs on that machine gets restart automatically. We don’t want that happen during the time when we are fixing it. So temporarily disable the crs autostart on that node is necessary.

***Related document on metalink:
Oracle notes: Note:298073.1

The CRS profiles for these resources must be modified for the new CRS behavior
to take effect for all RAC databases installed on the cluster. If, however,
the affect of the change is to be limited to a subset of installed databases,
the list of resources needs to be filtered further. (The rest of this section
should be skipped if the new CRS behavior is to be in effect for all databases
installed on the cluster.)
Please note that since more than one database may be installed on a cluster,
to modify the level of protection for a particular database, one must identify
the resources that represent entities of this database. This may be easily
accomplished since the names of the resources belonging to the above- stated
types always start with ora.. For instance, ora.linux.db
means that the resource belongs to the database named linux. Only resources of
the above-enumerated types that belong to the selected databases will need to
have their profiles modified.
MODIFYING RESOURCE PROFILES
Please note that Oracle strongly discourages any modifications made to CRS
profiles for any resources starting with . Never make any modifications to
CRS profiles for resources but the ones explicitly described below in
this document.

To modify a profile attribute for a resource, the following steps must be
followed:
1.Generate the resource profile file by issuing the following command:
crs_stat -p resource_name > $CRS_HOME/crs/public/resource_name.cap

2.Update desired attributes by editing the file created in step 1.

3.Commit the updates made as a part of the previous step by issuing the
following command
crs_register -u resource_name

4. Verify the updates have been committed by issuing the following command
crs_stat -p resource_name

For each of the resources identified as a part of the preceding section, the
following modifications must be made:
1.Resources of type inst must have the following attributes modified
AUTO_START must be set to 2
RESTART_ATTEMPTS must be set to 0 or 1. The former value will prevent
CRS from attempting to restart a failed instance at all while the latter
will grant it a single attempt; if this only attempt is unsuccessful,
CRS will leave the instance as is.
2.Resources of type db, srv, cs must have the following attributes modified
AUTO_START must be set to 2

***Practice steps:
1. Objective: to disable the crs autostart on node vanpgprodb05
2. catch all the resources profile on vanpgprodb05
1). from vanpgprodb01 (at that time the vanpgrpodb05 is down), run these catch commands
$crs_stat -p ora.p10c.p10c5.inst>$CRS_HOME/crs/public/ora.p10c.p10c5.inst.cap
$crs_stat -p ora.vanpgprodb05.ASM3.asm>$CRS_HOME/crs/public/ora.vanpgprodb05.ASM3.asm.cap
$crs_stat -p ora.vanpgprodb05.gsd>$CRS_HOME/crs/public/ora.vanpgprodb05.gsd.cap
$crs_stat -p ora.vanpgprodb05.LISTENER_VANPGPRODB05.lsnr>$CRS_HOME/crs/public/ora.vanpgprodb05.LISTENER_VANPGPRODB05.lsnr.cap
$crs_stat -p ora.vanpgprodb05.ons>$CRS_HOME/crs/public/ora.vanpgprodb05.ons.cap
$crs_stat -p ora.vanpgprodb05.vip>$CRS_HOME/crs/public/ora.vanpgprodb05.vip.cap

2). editing these .cap files, change parameter autostart=2 (not autostart).

3). crs_register -u resource_name
$crs_register -u ora.p10c.p10c5.inst
$crs_register -u ora.vanpgprodb05.ASM3.asm
$crs_register -u ora.vanpgprodb05.gsd
$crs_register -u ora.vanpgprodb05.LISTENER_VANPGPRODB05.lsnr

4). use crs_stat -p resource_name to verify the parameter has been changed
crs_stat -p|grep AUTO_START=2 -B 7

5). reboot the node vanpgprodb05 now, after reboot
[oracle@vanpgprodb01 public]$ crs_stat -t
Name Type Target State Host
————————————————————
ora.p10c.db application ONLINE ONLINE vanp…db02
ora….c1.inst application ONLINE ONLINE vanp…db01
ora….c2.inst application ONLINE ONLINE vanp…db02
ora….c5.inst application OFFLINE OFFLINE
ora….SM1.asm application ONLINE ONLINE vanp…db01
ora….01.lsnr application ONLINE ONLINE vanp…db01
ora….b01.gsd application ONLINE ONLINE vanp…db01
ora….b01.ons application ONLINE ONLINE vanp…db01
ora….b01.vip application ONLINE ONLINE vanp…db01
ora….SM2.asm application ONLINE ONLINE vanp…db02
ora….02.lsnr application ONLINE ONLINE vanp…db02
ora….b02.gsd application ONLINE ONLINE vanp…db02
ora….b02.ons application ONLINE ONLINE vanp…db02
ora….b02.vip application ONLINE ONLINE vanp…db02
ora….SM3.asm application OFFLINE OFFLINE
ora….05.lsnr application OFFLINE OFFLINE
ora….b05.gsd application OFFLINE OFFLINE
ora….b05.ons application ONLINE ONLINE vanp…db05
ora….b05.vip application ONLINE ONLINE vanp…db05

Note: for ONS, the autostart is “AUTO_START=always”, and you can’t take vip off

6). the disabling works! don’t forget the change the autostart back when problem gets resolved. repeat steps 2)-4)

Adds-on: if you want to stop the autostart for css daemon either, then do this:
/etc/init.d/init.cssd stop

If you want to stop it from autostarting after bootup;
[root@vanpgprodb06 rc3.d]# /etc/init.d/init.crs disable
Automatic startup disabled for system boot.

December 5, 2008

Moving Table/Index to a New Segment or Tablespace

Filed under: [System Performance tuning] — zhefeng @ 11:54 am

The following statement moves the my_table to a new segment, specifying new storage parameters:

ALTER TABLE my_table MOVE
STORAGE ( INITIAL 20K
NEXT 40K
MINEXTENTS 2
MAXEXTENTS 20
PCTINCREASE 0 );

Moving a table changes the rowids of the rows in the table. This causes indexes on the table to be marked UNUSABLE, and DML accessing the table using these indexes will receive an ORA-01502 error. The indexes on the table must be dropped or rebuilt. Likewise, any statistics for the table become invalid and new statistics should be collected after moving the table.

If the table includes LOB column(s), this statement can be used to move the table along with LOB data and LOB index segments (associated with this table) which the user explicitly specifies. If not specified, the default is to not move the LOB data and LOB index segments.

To move a TABLE TO another TABLESPACE, issue the following command:
ALTER TABLE [table_name] MOVE TABLESPACE [new_tablespace];

To move an INDEX, use the following command:
ALTER INDEX [index_name] REBUILD TABLESPACE [new_tablespace];

To move the LOB when moving the table, use the following:
ALTER TABLE [table_name] MOVE TABLESPACE [new_tablespace] LOB (lob_item) STORE AS (TABLESPACE [another_new_tablespace]);

To move the PARTITION TABLE to another TABLESPACE, use:
ALTER TABLE [table_name] MOVE PARTITION [partition_name] TABLESPACE [new_tablespace];

December 4, 2008

Change Schema Name or owner on Tables and Stored Procedures in SQL Server 2005

Filed under: 3. MS SQL Server — zhefeng @ 4:49 pm

i found a useful doc from http://www.orcsweb.com/articles/change_schema_name.aspx

“Change Schema Name on Tables and Stored Procedures in SQL Server 2005″
By Steve Schofield
April 26, 2006

This article shows how to change the ‘schema’ name on an object from ‘username’ to ‘dbo’ in SQL Server 2005. The script generates code you have to copy, paste, and run on the database.

Change stored procedure owner in SQL Server 2005

Note: This is the raw query:
SELECT ‘ALTER SCHEMA dbo TRANSFER ‘ + s.Name + ‘.’ + p.Name FROM
sys.Procedures p INNER JOIN sys.Schemas s on p.schema_id = s.schema_id
where s.Name = ‘CHANGE_ME_Username’

It would create this kind of output:

* ALTER SCHEMA dbo TRANSFER steveschofield.spAuthors1
* ALTER SCHEMA dbo TRANSFER steveschofield.spAuthors2
* ALTER SCHEMA dbo TRANSFER steveschofield.spAuthors3

You would run the output in a new query window. After executing the statements, refresh SQL Management studio; the stored procedures would be updated to dbo.spAuthors1, dbo.spAuthors2, dbo.spAuthors3.

Change table owner in SQL Server 2005

Click here for an article that describes the syntax, it uses ‘sp_changeobjectowner’ which will not be supported in future SQL Server revisions however it works in SQL Server 2005.
declare @OldOwner varchar(100) declare @NewOwner varchar(100) set @OldOwner = ‘OldOwner’ set @NewOwner = ‘NewOwner’ s

elect ‘sp_changeobjectowner ”[‘ + table_schema + ‘].[‘ + table_name + ‘]”, ”’ + @NewOwner + ”’ go
from information_schema.tables where Table_schema = @OldOwner

December 2, 2008

consolidated MySQL manual and troubleshooting notes

Filed under: [MySQL] — zhefeng @ 1:35 pm

This is a consolidated MySQL manual and troubleshooting notes

***1. Installation of the MySQL (version 5.0.45)
There are two methods for installing MySQL:
1). Linux native rpm package.
Linux always include mysql server as its standard system rpm package, so if you are lucky after you install the linux the mysql is always there. if it’s not there or the version is too low, you can use yum(rhn_register) to install/update it:
#yum install mysql
#yum update mysql

After installation, the default location of mysql will be under /usr/bin
The log file will be under: /var/log/mysqld.log
There is “mysql.server” or “mysqld” or “mysql” will be put into /etc/init.d for auto-start
Backgroud Process: mysqld_safe

2). Customized installation
For example: create user, make folder, copy installation file
#cd /databases
#mkdir MySQL
#groupadd mysql
#useradd -g mysql mysql
#gunzip –sysconfdir=/etc \
> –localstatedir=/usr/local/mysql/data \
> –with-charset=utf8 \

#./scripts/mysql_install_db –user=mysql
#mkdir /var/run/mysqld
#chown mysql:mysql /var/run/mysqld

#/databases/MySQL/5.0.45/bin/mysqld_safe &

After successful installtion you will get comments like below:
{To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/databases/MySQL/5.0.45/bin/mysqladmin -u root password ‘new-password’
/databases/MySQL/5.0.45/bin/mysqladmin -u root -h vanpgcmsdb03 password ‘new-password’
See the manual for more instructions.
You can start the MySQL daemon with:
cd /databases/MySQL/5.0.45 ; /databases/MySQL/5.0.45/bin/mysqld_safe &

You can test the MySQL daemon with mysql-test-run.pl
cd mysql-test ; perl mysql-test-run.pl}

***2. Start mysql
There are so many ways to start mysql (i am still confused by some)
1). run “mysqld_safe &”
This method run the process directly and you got the same process name if you use ps to check.
2). #service mysqld start (stop, status)
This one by starting the mysql daemon to start the process
3). #/etc/init.d/mysqld start or #/etc/init.d/mysql start (for earlier version)
This is same as service start.

***3.login with root and validate the installation
Remeber! the “root” user for mysql is not the unix “root” user indeed, but you can set them for the same passwd
And you can use “#mysqlcheck -V” to check the version
or “#mysqladmin version” to check running
or use perl script test if you have mysql-test folder, cd mysql-test ; perl mysql-test-run.pl
1). normally login with root is easy:
#mysql -u root –didn’t put passwd here because by default mysql root account password is blank

***4.trouble shooting
1). Error 1: Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’
When connecting to a MySQL server located on the local system, the mysql client connects thorugh a local file called a socket instead of connecting to the localhost loopback address 127.0.0.1. For the mysql client, the default location of this socket file is /tmp/mysql.sock. However, for a variety of reasons, many MySQL installations place this socket file somewhere else like /var/lib/mysql/mysql.sock.

While it is possible to make this work by specifying the socket file directly in the mysql client command

mysql –socket=/var/lib/mysql/mysql.sock …

it is painful to type this in every time. If you must do so this way (because you don’t have permissions to the file in the solution below), you could create an alias in your shell to make this work (like alias mysql=”mysql –socket=/var/lib/mysql/mysql.sock” depending on your shell).

To make your life easier, you can make a simple change to the MySQL configuration file /etc/my.cnf that will permanently set the socket file used by the mysql client. After making a backup copy of /etc/my.cnf, open it in your favorite editor. The file is divided into sections such as:

[mysqld]
datadir=/usr/local/mysql/data
socket=/var/lib/mysql/mysql.sock

[mysql.server]
user=mysql
basedir=/usr/local/mysql

[mysqld_safe]
log-error=/var/log/mysqld.log

If there is not currently a section called [client], add one at the bottom of the file and copy the socket= line under the [mysqld] section such as:

[client]
socket=/var/lib/mysql/mysql.sock

If there is already a [client] section in the my.cnf file, add or edit the socket line as appropriate. You won’t need to restart your server or any other processes. Subsequent uses of the mysql client will use the proper socket file.
If the mysql.socket file is not existed in any location, just restart mysqld and it will automatically generate one.

2).Error 2: Could not open connection ‘default’: 1045 Access denied for user ‘root’@’localhost’ or forgot root password
step1: edited the file /etc/my.cnf at the [mysqld] section
added this line: skip-grant-tables
step2: /etc/init.d/mysql.server restart
step3: mysql -u root could login successfully.
step4: reset the password
use gui admin to change the root password or:
# mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD(‘your_new_password’) where USER=’root’;
mysql> FLUSH PRIVILEGES;
step5: comment out the “skip-grant-tables” in /etc/my.cnf
step6: restart the instance/daemon without the –skip-grant-tables option.
You should be able to connect with your new password.
# mysql -u root -p
Enter password: your_new_password

3).Error 3: [host] is not allowed to connect to this MySQL Server
This is because the remote host hasn’t been grant the root access. To wide open the root remote managing, run:
mysql>use mysql
mysql>GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘yourpassword’;
mysql>flush privileges;

Blog at WordPress.com.