2008. 9. 18. 22:18 투자
2008. 9. 17. 22:29 오라클
This document mainly discusses few generic concepts on sysdba authentication and corresponding troubleshooting steps , which will be helpful in resolving the error ORA-1031 insufficient privileges, if not at least in isolating the cause.
This document also includes few troubleshooting steps helpful in resolving this error if faced by non sysdba users.
Most of the oracle components like RMAN, Enterprise Manager, ASM connects to the database as sysdba , The concepts and troubleshooting steps discussed in this documents also applies in such scenarios in which If any of these components are failing with ORA-1031.
The documentation is subject to further modifications and enhancements.
1. A local user can connect to the database as sysdba using either OS authentication or by using password file authentication.
2. A user from a remote machine can connect to the database as sysdba using password file authentication .
From 11g a remote user can also connect to the database as sysdba using kerberos
For more details on remote sysdba authentication using kerberos please refer to 11g New Features Guide.
1. The following syntax is used while OS Authentication
sqlplus / as sysdba
2. A SQLNET.AUTHENTICATION_SERVICES controls the operation system authentication.
On unix platforms setting the value of this parameter to " ALL " or removing this parameter from SQLNET.ORA will allow the Operating system users to authenticate to the database with out specifying the password in other case[setting the value to NONE] the authentication will fail with ORA- 1031.
eg : SQLNET.AUTHENTICATION_SERVICES=(ALL) will allow the OS authentication
SQLNET.AUTHENTICATION_SERVICES=(NONE) will fail the OS authentication
3. The Operating system user should belong to OSDBA group in order to login as sysdba and the user should belong to OSOPER in order to login a sysoper.
On unix based platforms these groups by default would be DBA, OPER and in windows these would be ORA_DBA ,ORA_OPER.
Please refer to the operating system specific Oracle documentation for information about creating the OSDBA and OSOPER groups
1. Remote sysdba connections attempted with a user name and password uses password file authentication
2. The following syntax is used while using a password file authentication
sqlplus <sysdba user>/<password> as sysdba
The following syntax is used while using a password file authentication connecting to the database as remote user
sqlplus <sysdba user>/<password>@<NET SERVICE NAME> as sysdba
2. Password file authentication is enabled by setting the database parameter remote_login_password file to "shared" or "exclusive".
SQL> alter system set remote_login_password file=exclusive scope=spfile;
3. On unix based platforms a password file is created by default during database installation with an entry of sys under directory $ORACLE_HOME/dbs/ and on windows the file is created under %ORACLE_HOME%\database\
4. Granting each database user a sysdba or sysoper privilege adds the user to the password file in the background.
For more information on password file setup and maintenance please refer the following oracle documentation
" Creating and Maintaining a Password File " section of " Chapter 1 " of " Oracle Database Administrator's Guide "
When both OS authentication and password file authentication is enabled than OS Authentication overrides password file authentication.
i.e sysdba can be logged with any user name and password, only the operating system user will be verified.
sqlplus harry/harry as sysdba will be able to login to the database though harry is not a database user.
1. Check whether the OS user is part of DBA group and OPER group if not add the user to these groups.
2. Check the SQLNET.AUTHENTICATION_SERVICES parameter in the SQLNET.ORA .
On unix based platforms either this parameter should not be present or should be set to ALL.
On windows this parameter should be set to NTS.
3. If the OS user is a domain user in the windows domain than check whether the database service is started with a domain user , if not start the database service with the
domain user.
Check whether the domain is added to the ORA_DBA or ORA_<SID>_DBA group.
Check if a non domain[Local] user can able to login to the database. If so there could be problem with the domain settings ,contact the system administrator and the network
administrator reporting the same.
If the local user is also failing to login than follow the remaining steps specified in this troubleshooting document.
4. If a scheduled script on windows is causing the error than the user calling the script must be a privileged user.The AT command, by default, runs as the NT SYSTEM
account.The SYSTEM account is not a privileged Oracle user.
The Task Scheduler and the AT command are not the same thing.They work with each other.The Task Scheduler service must be started for any AT tasks to run.
When specifying the user account to use for tasks scheduled by AT, this must be set in the "Scheduled Tasks" folder and not through the Task Scheduler service in the
service control panel.
Do this to set the AT service logon account in the "Scheduled Tasks" folder
1) Open "Control Panel"
2) Click on "Scheduled Tasks"
3) On the tool bar, click on "Advanced"
4) Click on "AT Service Account"
5) Choose "This Account:"
6) Specify a Windows account name and password that is part of the ORA_DBA.
5. There are chances that a confusion in windows service might me causing this issue, so to isolate the cause create a new windows service for the instance in any of the
failing machine and check if this fails by following the below steps :
Delete the SID and services:
1). Open a Command Prompt window:
- Click on the START button.
- Click on RUN.
- Type in: command
- Press OK.
2). Type in the following command: ORADIMxx -DELETE -SID <sid>
where: xx stands for the Oracle release (i.e., 73 or 80)
<sid> is the sid name of your database (i.e., ORCL)
In 8i and 9i, the command is just "oradim" (i.e., no xx)
3). Recreate the sid and services: ORADIMxx -NEW -SID sid -INTPWD password
-STARTMODE AUTO -PFILE <full path to initsid.ora>
6. There is a Chance that improper SGA might be causing the issue,if the size of the SGA was too large for the amount of physical memory than reducing the size of the SGA
eliminates the errors.
so please perform the below checks to troubleshoot the same :
Review the INIT.ORA file. You will find that there are some large entries affecting the size of memory used. Lower those parameters.
The SGA items to look at are:
SORT_AREA_SIZE
DB_BLOCK_BUFFERS
SHARED_POOL_SIZE
LOG_BUFFER.
7. If the failing user is the root user on UNIX platforms than check the userid and primary group to which the user belongs to by using the operating system command " id " .
In general a Unix root user will not have its primary group as DBA and more over the id of the root user would be 0, changing the id of the root user is not recommended as it may effect other application, so modify the root user inorder to make the primary group as dba.
8. If the issue is happening only on HP UX platforms than you may be hitting a know issue which is discussed in the below metalink document
Note 308151.1 Connect / AS SYSDBA Results In Ora-01031
9. There are cases where though a user name is manually added to the ORA_DBA group and is visible in the ORA_DBA group , a underlying windows interpretation of the username might
be different for unknown reasons .
But this can be verified by using a Microsoft API " NetUserGetLocalGroups " Function. by using this API we can be able to check if the username failing is actually a part of
the ORA_DBA group with respect to the underlying OS.
The following Microsoft knowledge base document speaks about this API :
http://msdn.microsoft.com/en-us/library/aa370655(VS.85).aspx
Please ask you system administrators to use the sample code specified in the document to validate the user by running the code on the failing machine as well as on the
domain controller.
The API returns all the groups the user belongs to , and if it is found that the appropriate groups [ like DBA ] is not reflected in the output than the corresponding
subscription has to be reissued and if the problem persists than you may have to contact the Microsoft support team.
10. On Unix based platforms a diagnostic C program will help in retrieving all the groups a user belongs to, the following metalink document contains the diagnostic program :
Note 67984.1 UNIX: Diagnostic C program for ORA-1031
If a local or remote sysdba connection fails with ORA-01031 than consider following factors :
1. The database parameter remote_login_passwordfile has to be set to either EXCLUSIVE or SHARED .
SQL> ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;
restart the database for the change to take effect.
2. A password file is created in $ORACLE_HOME/dbs with option " nosysdba=n " . In general the name of the file would be in the format orapw<SID> .
In case of uncertainity recreate the password file using the below syntax :
$ > orapwd file=$ORACLE_HOME/dbs/orapw<sid> password=<password> force=y nosysdba=nrestart the database .
The path to the password file %ORACLE_HOME%\database\PWD%ORACLE_SID%.ORA on a Microsoft Windows machine.
3. The connecting user needs to have sysdba privilege in the target database . The same can be confirmed by querying V$PWFILE_USERS
1. A database user
2. An external user
3. A global user
4. A user authenticated by middle tier
For more details please refer to Chapter10 of Oracle Database Security Guide , which can be accessed by using the following link :
http://download.oracle.com/docs/cd/B19306_01/network.102/b14266/admnauth.htm#i1006738
If a non sysdba user is failing to authenticate to the database with ORA-01031 than :
1. Check whether the user has a "CONNECT" role or "CREATE SESSION" system privilege granted by using the following SQL statements
If not granted to the user than ask the DBA to grant the same
2. If a datavault is installed and the user is trying to access a realm protected schema than check whether the user is the participant of the realm , if not add the user as realm participant .
The below link explains the steps to add a participant to a realm.
http://download.oracle.com/docs/cd/B19306_01/server.102/b25166/cfrealms.htm#CHDFGFJJ
3. In case of a remote database user check whether the target database is the appropriate one. In most of the case in an environment hosting multiple databases there are chances that the NET SERVICE NAME used may resolve to inappropriate database resulting in ORA-1031 .
Use command line tools like TNSPING, ipconfig and nslookup to check the hostname name and the ip resolved corresponding to the hostname. Take the help of network administrator if necessary.
4. In case of an external user authenticated by an operating system check whether the following database parameter is set to true :
SQL> show parameter remote_OS_authent.
If set to false than set the same to true by using the following SQL statement
SQL>Alter system set remote_os_authent=true scope=spfile;
restart the database.
Setting REMOTE_OS_AUTHENT to TRUE can cause a security exposure, because it lets someone using a non-secure protocol, such as TCP, perform an operating system-authorized login .
REMOTE_OS_AUTHENT is a depriciated parameter from 11g
Apart from the above parameter also check whether the SQLNET.ORA parameter SQLNET.AUTHENTICATION_SERVICES is set to the appropriate value as discussed earlier in this document
Discussion on Network Authenticated external users, Proxy users, Global users is out of the scope of this document.
SELECT * FROM USER_ROLE_PRIVS ;
SELECT * FROM USER_SYS_PRIVS ;If ORA-1031 is seen while or after upgrading database than performs the below checks :
a). Check the groups to which the user belongs to .
SQL> select * from V$PWFILE_USERS;
USERNAME SYSDB SYSOP SYSAS
------------------------------ ----- ----- -----
SYS TRUE TRUE FALSE
SCOTT TRUE FALSE FALSEb). Check the actual names of the ORDBA group in $ORACLE_HOME/rdbms/lib/config.s [ the file can be config.c in some operating systems]
If the ORADBA group in the config.s/config.c is not reflected in the groups list to which the usr belongs to than add the user to the group seen in config.s/config.c
Remove and move the CONFIG.O and relink the oracle, using the following steps :
1. Shutdown the database and other processes related to the ORACLE_HOME
2. Navigate to $ORACLE_HOME/rdbms/lib
3. Take a backup of the current CONFIG.O and delete it :
mv config.o to config.o.bkp
4. Check the config.s or config.c to verify whether the name of the 'dba' and 'oper' groups are appropriate, if not correct them accordingly
5. MAke a new CONFIG.O by using the below command :
make -f ins_rdbms.mk config.o ioracle
6. Relink oracle
1. Check whether the user has appropriate privilege to execute the failing SQL statement by using the following SQL statement:
SQL> select * from session_privs;If any of the required privilege is missing than request your DBA to grant the same.
For example in order to create a table a user needs to create table or create any table privilege.
2. If a DDL statement like create table is failing with ORA-1031 than check the following :
sql>select guard_status from v$database;
guard_status
-------
ALLThe DDLs fail if the above parameter is set to ALL, the solution is to set this to NONE by executing the following statement
sql>alter database guard none;Though guard_status is a Data guard related parameter setting this to ALL will also affect a stand alone database.
If an explain plan on a query is failing with ORA-1031 than :
1. Check whether the user issuing the explain plan has a select privilege on the objects used if not grant a select privilege
SQL>conn sys/<pwd> as sysdba
SQL>SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE='<user name>';
SQL>SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE='<user name>';
2. Check whether the user has appropriate privileges on PLAN_TABLE if not grant the same
SQL>conn sys/<pwd> as sysdba
SQL>grant all on PLAN_TABLE to <user>;
3. If the above steps did not help than create a plan table in the user schema
SQL> conn <user>/<pwd>
SQL>@?/rdbms/admin/utxplan.sql2008. 9. 15. 18:31 투자
2008. 9. 12. 23:11 투자
도대체 중국정부는 증시를 부양할 생각이 있는 거긴 한거냐... 1년 내내 꼴아박고 있는데..도무지 믿음이 안가는 공산당 놈들.. 이젠 뭐 큰거 하나 발표할 때도 되지 않았니? 해도 해도 너무한다.. ========================================================= 中ㆍ홍콩증시 당분간 반전 힘들듯 | |||
| 기업실적ㆍ수급 악화…경기부양책 나와야 상승 | |||
| |||
|
중국과 홍콩 증시가 좀처럼 반전의 실마리를 찾지 못하고 있다. 경제 상황과 정부 정책, 수급에 이르기까지 증시를 둘러싼 환경 중 나쁘지 않은 것이 없기 때문이다. 전문가들조차 "현 상황에서는 바닥을 가늠하기 어렵다"며 "중국 정부의 증시 부양책을 기다릴 수밖에 없다"고 말했다. 12일 오전 11시 40분 현재 중국 상하이종합지수는 전날보다 0.30% 상승한 2085.12를 기록 중이며 홍콩 항셍지수와 H지수는 각각 0.33%, 0.40% 하락에 그쳐 안정을 찾는 모습을 보이고 있다. 전날 급락에 대한 반발 매수세가 들어왔고 중국 전기요금 인상에 대한 기대감이 커지고 있기 때문이다. 하지만 전반적인 증시 분위기는 크게 나아질 게 없는 상황이다. 일단 지난 10일 발표된 중국의 8월 물가지수에 대한 해석이 제각각이다. 소비자물가지수(CPI) 상승률이 전년 동월 대비 4.9% 증가에 그쳐 7월(6.3%)에 비해 하락했다는 사실에 무게를 두는 시각이 있는가 하면 생산자물가지수(PPI) 상승률은 10.1%로 7월보다 오히려 높아졌다는 점을 강조하는 시각도 존재한다. 중국 정부는 물가지수가 다시 상승할 수도 있다는 입장이다. 전날 중국 인민은행장이 "물가가 반등할 가능성이 여전히 존재한다"고 말한 것도 그런 맥락이다. 따라서 중국 정부는 당분간 경기 부양보다는 인플레이션 통제에 정책 초점을 맞출 가능성이 높다. 하지만 정부가 물가보다는 경기부양에 힘을 쏟아주기를 바랐던 투자자들에게 정부 반응은 실망스러운 것이다. 허재환 대우증권 연구원은 "7월 증시가 약세로 접어들면서부터 정부 경기부양책을 기대했던 투자자들이 실망감에 매물을 쏟아냈다"며 "개인투자자가 많은 중국 증시 특성상 투자심리 악화가 증시 하락에 미치는 영향이 크다"고 말했다. 경착륙 염려는 없다고 하지만 기업 실적 등 전반적인 경제 상황도 좋지 않다. 지난 2분기 10.1%를 유지한 중국 GDP 성장률은 하반기에는 9%대로 떨어질 것으로 보인다. 일부에서는 9%대를 유지하기도 힘들다는 의견을 내고 있다. 지난해 연간 GDP 성장률이 11.4%였으니 증가폭이 많이 둔화된 셈이다. 선전과 광둥에서 시작된 부동산 경기 침체 역시 베이징과 상하이 등으로 확산되고 있다. 기관투자가들이 주식 매수를 꺼리는 상황에서 개인투자자들은 펀드 환매에 나서면서 수급도 꼬여버린 상황이다. 홍콩 증시는 미국과 중국 악재만을 고스란히 반영하고 있다. 항셍지수와 H지수 주요 구성 종목이 금융주와 중국 부동산 기업이기 때문이다. 하루는 리먼브러더스 실적 악화 영향으로 급락하고 다음날은 중국 부동산시장 경색 소식으로 또다시 급락하는 형국이다. 조용찬 한화증권 연구원은 "지금은 우선순위에서 밀려나 있지만 주식시장이 추가 급락하는 건 중국 정부도 원하지 않을 것"이라며 "약세가 지속되면 대차거래와 선물시장 개설 허용 등 방안이 나올 수 있다"고 말했다. |
2008. 9. 12. 22:14 투자
9월 위기설, 무엇을 남겼나… 두달간 실체없는 공포에 금융시장 초토화 환율방어에만 외환보유액 200억弗 축내… 결국 국내 투자자 '눈물' 외국인만 배 불려 이번에도 ‘설(說)’뿐이었다. 온 나라를 ‘환란’공포로 몰아넣었던 ‘9월 위기설’은 최대 고비였던 외국인보유 채권만기일(9~10일)을 무사히 넘기면서 결국 자연 소멸됐다. 외국인들은 한국시장을 집단이탈하지 않았고, 외환부족사태도 없었다. 피해가 없었던 것은 다행스런 일이다. 하지만 위기설의 유령에 끌려 다니며 나라경제 전체가 뿌리째 휘청거렸던 지난 몇 달을 되돌아보면 ‘과연 한국의 시장, 한국의 투자자들은 환란 때보다 나아진 것이 무엇인가’란 질문을 던지게 한다. 전문가들은 이번 9월 위기설 파동의 책임이 정부, 시장, 투자자, 언론 모두에게 있다는 점을 강조하며, 우리나라 금융시장이 한단계 성숙되는 계기로 삼아야 한다고 지적하고 있다. 11일 금융계에 따르면 9월 위기설로 인해 우리경제가 입은 손실만도 어림잡아 100조원이 훨씬 넘는다. 위기설이 고개를 들기 시작한 6월말 이후 주식시장 시가총액은 무려 110조원이나 허공으로 증발했다. 한 증권사 관계자는 “주가하락이 모두 위기설 탓은 아니겠지만 가장 큰 요인이었던 점은 부인할 수 없다”며 “결국 수많은 개인주식투자자, 펀드투자자들이 위기설로 인해 재산손실을 입은 셈”이라고 말했다. 환율방어를 위한 시장개입으로 외환보유액도 150억달러 이상(약 17조원) 사라졌다. 지난 두 달간 시장개입금액은 200억달러를 훨씬 넘을 것으로 추산된다. 반면 외국인들은 9월 위기설 와중에 오히려 상당한 이익을 챙겼다. 가장 많은 채권만기가 몰려있던 10일 하룻동안 외국인들은 대량 처분후 한국시장을 떠날 것이란 위기설을 비웃기라도 하듯, 6,000억원이 넘는 채권을 순매수했다. 이달 들어 10일까지 외국인들은 모두 2조원이 넘는 채권을 순매수했는데, 위기설로 인한 금리상승 덕분에 평소보다 높은 8%대의 수익률을 보장 받게 된 것으로 전해졌다. 결국 9월 위기설은 국내 투자자들에겐 손실을 떠안기고, 외국인들의 배만 불린 셈이다. 그러나 누굴 탓할 수도 없다. 화(禍)를 자초한 것은 우리 자신이기 때문이다. 2,400억달러의 외환보유액을 가진 나라에서 70억달러 정도의 외국인채권 때문에 환란이 올 것이란 위기설은 애초 가설부터 잘못된 것이었다. 그런데도 투자자들은 사실보다는 소문에 귀를 기울이며 특유의 ‘쏠림’현상을 보여줬다. 외환ㆍ주식시장은 작은 충격에도 들끓는 특유의 냄비근성을 또다시 드러냈다. 시장이 흔들리면 정부라도 중심을 잡아야 하는데, 당국은 불길이 걷잡을 수 없이 번진 뒤에야 허겁지겁 소화기를 들었다. 언론보도 역시 춤을 췄다. 삼성경제연구소 권순우 연구원은 “금융은 신뢰와 같은 무형자본을 바탕으로 하는 만큼 소문에도 큰 영향을 받을 수 있다”며 “정부가 시장에 정확한 정보를 주고 해외언론이나 오피니언 리더와도 소통하는 등의 노력을 더 기울여야 한다”고 지적했다. 9월 위기설은 아직도 우리 경제가 ‘환란’의 그림자를 벗어나지 못했음을 의미한다. 이성태 한국은행총재도 이날 “외환위기로 한국경제가 큰 충격을 받았기 때문에 혹시나 하는 심리도 작용하지 않았나 싶다”면서 우리시장에 남아 있는 ‘환란 트라우마’(큰 외상으로 인한 스트레스장애)현상을 지적했다. 진정 위기를 막으려면, 부풀려진 위기설에 쉽게 휘둘리는 시장체질과 정부자세부터 바꿔야 한다는 것이 전문가들의 공통된 지적이다. 문준모 기자 moonjm@hk.co.kr |
2008. 9. 12. 17:36 펌질
지난 7월 25일, “마지막 강의”로 췌장암 말기와 사투하며
삶에 대한 긍정적 태도를 보여준 랜디 포쉬 미국 카네기 멜론 대학의
컴퓨터 학과 교수가 세상을 떠났습니다
그의 마지막 강의의 한글 번역을 보내드립니다.
“인생에서 장애물이 존재하는 이유는 이 장애물을 통해서
우리에게 꿈이 얼마나 간절한지를 깨닫게 하기 위해서이다...”
이 마지막 강의를 통해서 끝까지 좌절하지 않고 열정과
긍정적 적극적 사고로 살아야 한다는 것을 일러주고
그는 떠났습니다.
<‘마지막 강의’ 랜디 포쉬 카네기 멜론대 컴퓨터공학과 교수 >
죽음을 앞두고 마지막 강의를 한다면 어떤 애기를 하시겠어요?
저에겐 그런 엄청난 일이 실제로 일어났습니다.
“
8
이를 통해 인생에 왜 장애물이란 게 존재하는지 배웠습니다.
2
2008. 9. 10. 22:39 투자
2008. 9. 7. 20:08 좋아하는 음악
1. That Was Just Your Life
2. The End Of The Line
3. Broken, Beat & Scarred
4. The Day That Never Comes
5. All Nightmare Long
6. Cyanide
7. The Unforgiven III
8. The Judas Kiss
9. Suicide & Redemption
10. My Apocalypse
2008. 9. 4. 23:01 오라클
2008. 9. 1. 20:07 투자
invalid-file
