eygle.com   eygle.com
eygle.com  
 
留言簿 - Oracle Life - Powered by Eygle.com
eygle.com 我要留言
DBA的新年及圣诞礼物-《深入解析Oracle》
昵称
内容 页: 1 - << < 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 > >> - 404
# 43983
卧龙




To:
  你好,我买了你的书,写的不错,我只有慢慢看,我想问一个问题,比如我们服务器通过HBA卡连接到san架构的光纤交换机上,我安装oracle,选择设备要文件系统,还是asm系统,还是裸设备?对san的架构没有了解,不懂啊!
From: 卧龙
2008.01.16 07:17

版主选项: 回复 编辑
# 43858
lq




To:
  To: eygle
 您好。
在学习solaris字符集的时候遇到了一些问题。 我想修改solaris的默认字符集。
通过locale, 现在的系统环境如下:
LANG=ja
LC_CTYPE="ja"
LC_NUMERIC="ja"
LC_TIME="ja"
LC_COLLATE="ja"
LC_MONETARY="ja"
LC_MESSAGES="ja"
LC_ALL=
打开vi /etc/default/init 文件如下:
TZ=PRC
CMASK=022
LANG=ja

首先我修改/etc/default/init:
TZ=PRC
CMASK=022
LANG=zh
LC_ALL=zh

然后reboot,重起机器后,用locale,结果如下:
LANG=ja
LC_CTYPE="zh"
LC_NUMERIC="zh"
LC_TIME="zh"
LC_COLLATE="zh"
LC_MONETARY="zh"
LC_MESSAGES="zh"
LC_ALL="zh"

问题是:1,LANG=ja 为什么没有按照/etc/default/init 文件的设定变更。
2,判断当前solaris默认字符集是根据LANG,还是根据LC_ALL
3,这样设置solaris字符集是否正确
4,solaris字符集设置是不是就是系统语言环境设置
From: lq
2008.01.14 23:45

版主选项: 回复 编辑
# 43857
dreamer


来自: 深圳


To: eyge
  eygle,你好 ,还是redodb问题,之前有请教你。具体情况如下:我们用的oracle数据库,建有erp,kmoa,lissys三个数据库,给这三个数据库的redodb文件分配的大小一共为10G,现在redodb文件利用率已经为100%,现在10G空间主要被三个数据库中的undotbs01.dbf文件所占用,分别占用3G,2G,3.7G。像这种情况有什么好的解决方法吗,怎么解决呢?目前暂时的解决方法是将部分redodb移动到另外一个文件夹。
  谢谢。
From: dreamer
2008.01.14 23:19
To: dreamer
  [COLOR=blue]
undo表空间可以resize缩小的,也可以删除重建一个,我的网站有指导文章,你搜索一下
[/COLOR]
From: eygle
2008.01.15 19:21

版主选项: 回复 编辑
# 43854
trwolf


来自: beijing


To: eygle
  你好,我是清华大学出版社编辑涂荣。希望与您建立合作关系,期待您新的作品。如果您感兴趣,请与我取得联系。谢谢。
From: trwolf
2008.01.14 21:00
To: trwolf
  [COLOR=blue]谢谢关注,已经和几家出版所有着联系,近年可能会有几本书出版[/COLOR]
From: eygle
2008.01.15 19:21

版主选项: 回复 编辑
# 43853
dreamer


来自: shenzhen


To: eygle
  eygle,你好,我有个关于redodb文件的问题请教,我们公司oracle数据的redodb文件在12号和13号两天突然涨到了100%,具体应用为erp,公文系统,物流系统,在这些系统下面都有一个undotbs01.dbf文件,大小分别为3G,2G,3.7G。而redodb总的大小才10G,正常情况下redodb应该是不会增长的,请问突然涨到100%会是什么原因呢?
From: dreamer
2008.01.14 18:00
To: dreamer
  [COLOR=blue]
UNDO表空间可能会因为存在大事务而扩展,你说的不够清楚
“公文系统,物流系统,在这些系统下面都有一个undotbs01.dbf文件,大小分别为3G,2G,3.7G”
你有三个数据库么?
[/COLOR]
From: eygle
2008.01.14 22:46

版主选项: 回复 编辑
# 43852
oracle




To:
  eygle,你好,我看了你的循序渐进oracle中的1.2.4 oracle sid的含义,有些不解的是:
在同一个$ORACLE_HOME下面都执行了
export ORACLE_SID=eygle之后OS怎么区分两个不同的实例呢?
还有、如果是一台机器建两个版本一样的且名字一样的实例应该不可以吧?
谢谢……
期待您的回复……


From: oracle
2008.01.14 01:06
To: oracle
  [COLOR=blue]
你看错了吧?
"在同一个$ORACLE_HOME下面都执行了
export ORACLE_SID=eygle之后OS怎么区分两个不同的实例呢?"

是在不同$ORACLE_HOME下,你仔细看看!

[/COLOR]
From: eygle
2008.01.14 17:50

版主选项: 回复 编辑
# 43851
edward_kof




To: eygle
  eygle 你好:
  我在看您的书是深入浅出,第一章关于数据库启动使用SPFILE的问题,我在修改了SPFILE.ORA和SPFILE(SID).ORA后 stratup nomount 后系统提示
ORA-01078: failure in processing system parameters
LRM-00121: 'NOTE' is not an allowable value for 'remote_login_passwordfile'
在DATABASE文件夹下面有两个init.ora文件一个是initlwp.ora (lwp是SID) 还有一个不知道什么时候创建的inittest.ora LRM-00121是什么意识啊 请执教。谢谢
From: edward_kof
2008.01.13 21:05
To: edward_kof
  [COLOR=blue]
'remote_login_passwordfile' = NONE 吧,你写成了NOTE
[/COLOR]
From: eygle
2008.01.14 00:20

版主选项: 回复 编辑
# 43850
ysjseuawd




To: eygle
  你好:
  我们的系统一直困扰着我,采用的ORACLE 8.05的数据库,可是现在查询起来非常慢,希望老师能指点我该从什么地方入手解决这个问题,或者推荐我用什么软件测试一下,然后进行有针对性的优化!
 谢谢
From: ysjseuawd
2008.01.12 22:27
To: ysjseuawd
  [COLOR=blue]
从等待事件分析入手...
[/COLOR]
From: eygle
2008.01.14 22:47

版主选项: 回复 编辑
# 43849
dgbelt


来自: 东莞


To: 新年好吖
  哈哈..新年好吖..
我来看你了..
你有空也到我网站坐坐..
http://www.dgbelt.cn

From: dgbelt
2008.01.11 00:25

版主选项: 回复 编辑
# 43848
testmvb


来自: 山東


To: eygle
  eygle老師.有一個問題請教一下.
 有一個OLTP的數據庫環境.數據庫版本是10GR2,有一個大的分區表,在單機上運行一直OK,遷移到RAC環境後,大約每兩周左右就會出一次問題.通過ADDM發現這個語句出了問題:
select * from sfism4.r_wip_Tracking_t where key_part_sn=:B1;
查看它的執行計畫發現是全表掃描,但是在key_part_sn上有建索引,平時索引也正常使用,但是忽然就變更了執行計畫,至今已經有3次,大概每次都是晚上10-12點左右.通過dbms_status.gather_table_statistics重新對表進行分析,解決問題.但是莫名其妙過一段時間又出現了.現在搞得我很頭痛.請問eygle老師可能是哪方面的原因 ?

From: testmvb
2008.01.09 23:37

版主选项: 回复 编辑

页: 1 - << < 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 > >> - 404
我要留言
Copyright © 2003~2012 eygle.com All Rights Reserved.
Powered by: www.eygle.com