The following error was reported when starting the Observer
DGMGRL> start observer
Error: ORA-16814: duplicate name specified for observer
Database version 19.11.0
Patterns are: MaxPerformance
GMGRL> show configuration
Configuration - xxx
Protection Mode: MaxPerformance
Members:
xxx - Primary database
xxx - Physical standby database
The mode before operation was MaxAvailability, changed to MaxPerformance, and still failed to start observer.
ORA-16814: Alternate database AlternateLocation retransmission setting is incorrect
I do not know how to check this. How can I fix the problem?
Related
I am trying to run a Spring loader. That loader will take the data from the csv file and insert into oracle database. It starts well, after processing some records, i am getting the below error.
'ORA-12516 - TNS:listener could not find available handler with matching protocol stack'
Note : No other jobs were running at that time. Only this job was running.
processes -- 45 (CURRENT_UTILIZATION) -- 51 (MAX_UTILIZATION)
sessions -- 53 (CURRENT_UTILIZATION) -- 61 (MAX_UTILIZATION)
show parameter processes (processes - integer - 300)
show parameter session (sessions - integer - 480)
The thing is, the same batch program is running fine in another server, which has the same set of above configurations.
Since its a new server, anything i am missing in regards to oracle.? Can someone guide.
I have about 4000 files (avg ~7MB each) input.
My pipeline always failed on the step CoGroupByKey when the data size reach about 4GB.
I tried to limit only use 300 file then it run just fine.
In case of fail, the logs on GCP dataflow only show:
Workflow failed. Causes: S24:CoGroup Geo data/GroupByKey/Read+CoGroup Geo data/GroupByKey/GroupByWindow+CoGroup Geo data/Map(_merge_tagged_vals_under_key) failed., The job failed because a work item has failed 4 times. Look in previous log entries for the cause of each one of the 4 failures. For more information, see https://cloud.google.com/dataflow/docs/guides/common-errors. The work item was attempted on these workers:
store-migration-10212040-aoi4-harness-m7j7
Root cause: The worker lost contact with the service.,
store-migration-xxxxx
Root cause: The worker lost contact with the service.,
store-migration-xxxxx
Root cause: The worker lost contact with the service.,
store-migration-xxxxx
Root cause: The worker lost contact with the service.
I digging through all logs in Logs Explorer. Nothing else indicate error other than the above, even my logging.info and try...except code.
Think this relate to the memory of the instances but I didn't digging into that direction. Because it kindna what I don't want to worry about when I am using GCP services.
Thanks.
I created a private image of a Google compute engine persistent disk, called primecoin01.
Later on, I'm trying to create a new image. It fails by saying the regexp is invalid both in listing the images and during gcloud.compute.instances.delete - the 1st step in using my persistent disk to create an image. It let me create the image name and now I'm unable to use the commands gcloud compute images list or gcloud compute instances delete instance-0 --keep-disks boot. I do not know a way to delete this image from my list.
primecoin01 certainly meets the regular expression criteria, and I have no clue why it named the image apparently ``primecoin01 All help greatly appreciated.
Details below:
C:\Program Files\Google\Cloud SDK>gcloud compute images list
NAME PROJECT ALIAS DEPRECATED STATUS
centos-6-v20141021 centos-cloud centos-6 READY
centos-7-v20141021 centos-cloud centos-7 READY
coreos-alpha-494-0-0-v20141108 coreos-cloud READY
coreos-beta-444-5-0-v20141016 coreos-cloud READY
coreos-stable-444-5-0-v20141016 coreos-cloud coreos READY
backports-debian-7-wheezy-v20141021 debian-cloud debian-7-backports READY
debian-7-wheezy-v20141021 debian-cloud debian-7 READY
container-vm-v20141016 google-containers container-vm READY
opensuse-13-1-v20141102 opensuse-cloud opensuse-13 READY
rhel-6-v20141021 rhel-cloud rhel-6 READY
rhel-7-v20141021 rhel-cloud rhel-7 READY
sles-11-sp3-v20140930 suse-cloud sles-11 READY
sles-11-sp3-v20141105 suse-cloud sles-11 READY
sles-12-v20141023 suse-cloud READY
ERROR: (gcloud.compute.images.list) Some requests did not succeed:
- Invalid value '``primecoin01'. Values must match the following regular expression: '(?:(?:[-a-z0-9]{1,63}\.)*(?:[a-z]
(?:[-a-z0-9]{0,61}[a-z0-9])?):)?(?:[0-9]{1,19}|(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?))'
and
C:\Program Files\Google\Cloud SDK>gcloud compute instances delete instance-0 --keep-disks boot
ERROR: (gcloud.compute.instances.delete) Unable to fetch a list of zones. Specifying [--zone] may fix this issue:
- Invalid value '``primecoin01'. Values must match the following regular expression: '(?:(?:[-a-z0-9]{1,63}\.)*(?:[a-z] (?:[-a-z0-9]{0,61}[a-z0-9])?):)?(?:[0-9]{1,19}|(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?))'
and
C:\Program Files\Google\Cloud SDK>gcloud compute instances delete instance-0 --keep-disks boot --zone us-central1-b
The following instances will be deleted. Attached disks configured to
be auto-deleted will be deleted unless they are attached to any other
instances. Deleting a disk is irreversible and any data on the disk
will be lost.
- [instance-0] in [us-central1-b]
Do you want to continue (Y/n)? y
ERROR: (gcloud.compute.instances.delete) Failed to fetch some instances:
- Invalid value '``primecoin01'. Values must match the following regular expression: '(?:(?:[-a-z0-9]{1,63}\.)*(?:[a-z]
(?:[-a-z0-9]{0,61}[a-z0-9])?):)?(?:[0-9]{1,19}|(?:[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?))'
It seems to be a validation error when creating the disk and the name is not correct. Are you still having the same issue?
A way to create a 'snapshot' of your disk will be to use the dd Linux command to burn your image and then tar the file to create an image from this file.
I have put some effort into getting Kafka to run on windows 32 (company issued laptop - certainly not my choice..).
I was successful to create a handful of topics. But after stopping/restarting kafka it is unable to re-read those topics. Here is the startup logs
[2014-05-29 12:26:23,097] INFO [ReplicaFetcherManager on broker 0] Removed fetcher for partitions [vip_ips_alerts,0],[calls,0],[dropped_calls,0],[calls_online,0],[calls_no_phone,0] (kafka.server.ReplicaFetcherManager)
[2014-05-29 12:26:23,106] ERROR [KafkaApi-0] error when handling request Name:LeaderAndIsrRequest;Version:0;Controller:0;ControllerEpoch:4;CorrelationId:5;ClientId:id_0-host_null-port_9092;Leaders:id:0,host:S80035683-SC01.mycompany.com,port:9092;PartitionState:(vip_ips_alerts,0) -> (LeaderAndIsrInfo:(Leader:0,ISR:0,LeaderEpoch:3,ControllerEpoch:4),ReplicationFactor:1),AllReplicas:0),(calls,0) -> (LeaderAndIsrInfo:(Leader:0,ISR:0,LeaderEpoch:1,ControllerEpoch:4),ReplicationFactor:1),AllReplicas:0),(dropped_calls,0) -> (LeaderAndIsrInfo:(Leader:0,ISR:0,LeaderEpoch:3,ControllerEpoch:4),ReplicationFactor:1),AllReplicas:0),(calls_online,0) -> (LeaderAndIsrInfo:(Leader:0,ISR:0,LeaderEpoch:3,ControllerEpoch:4),ReplicationFactor:1),AllReplicas:0),(calls_no_phone,0) -> (LeaderAndIsrInfo:(Leader:0,ISR:0,LeaderEpoch:3,ControllerEpoch:4),ReplicationFactor:1),AllReplicas:0) (kafka.server.KafkaApis)
java.util.NoSuchElementException: key not found: \tmp\kafka-logs
at scala.collection.MapLike$class.default(MapLike.scala:225)
at scala.collection.immutable.Map$Map1.default(Map.scala:107)
at scala.collection.MapLike$class.apply(MapLike.scala:135)
at scala.collection.immutable.Map$Map1.apply(Map.scala:107)
at kafka.cluster.Partition.getOrCreateReplica(Partition.scala:91)
at kafka.cluster.Partition$$anonfun$makeLeader$2.apply(Partition.scala:175)
at kafka.cluster.Partition$$anonfun$makeLeader$2.apply(Partition.scala:175)
at scala.collection.immutable.Set$Set1.foreach(Set.scala:86)
at kafka.cluster.Partition.makeLeader(Partition.scala:175)
at kafka.server.ReplicaManager$$anonfun$makeLeaders$5.apply(ReplicaManager.scala:305)
at kafka.server.ReplicaManager$$anonfun$makeLeaders$5.apply(ReplicaManager.scala:304)
at scala.collection.mutable.HashMap$$anonfun$foreach$1.apply(HashMap.scala:95)
at scala.collection.mutable.HashMap$$anonfun$foreach$1.apply(HashMap.scala:95)
at scala.collection.Iterator$class.foreach(Iterator.scala:772)
at scala.collection.mutable.HashTable$$anon$1.foreach(HashTable.scala:157)
at scala.collection.mutable.HashTable$class.foreachEntry(HashTable.scala:190)
at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:45)
at scala.collection.mutable.HashMap.foreach(HashMap.scala:95)
at kafka.server.ReplicaManager.makeLeaders(ReplicaManager.scala:304)
at kafka.server.ReplicaManager.becomeLeaderOrFollower(ReplicaManager.scala:258)
at kafka.server.KafkaApis.handleLeaderAndIsrRequest(KafkaApis.scala:100)
at kafka.server.KafkaApis.handle(KafkaApis.scala:72)
at kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:42)
at java.lang.Thread.run(Thread.java:744)
Now I am OK to drop /re-create the topics. I have actually done so several times as part of my investigation (e.g. to ensure no Zookeeper corruption), Any tips on how to get a kafka server up on this out-of-date O/S would be appreciated.
Misinterpret log.dir is a huge source of pain in kafka in both unixes and windows.
It seems that the exception was caused in the following statement in
Partition. replicaManager.highWatermarkCheckpoints(log.dir.getParent)
It tries to look up in a map of highWatermarkCheckpoint files to find
the key "\kafka8-tmp\kafka-logs", but it doesn't exist. We register
the keys using the property value in log.dirs.
source
Make sure you don't have trailing slashes and that new java.io.File("\tmp\kafka-logs").getParent is not distorted (I don't have windows machine right next to me to figure out all this forward/backward slashes by myself).
I am getting a race condition warning while running multiple imports simultaneously to openTSDB. Following is one of the log sequences showing the race condition.
2013-08-21 14:34:24,745 INFO [main] UniqueId: Creating an ID for
kind='tagv' name='25447'
2013-08-21 14:34:24,747 INFO [main] UniqueId: Got ID=307 for
kind='tagv' name='25447'
2013-08-21 14:34:24,752 WARN [main] UniqueId: Race condition: tried
to assign ID 307 to tagv:25447, but CAS failed on
PutRequest(table="tsdb-uid", key="25447", family="id",
qualifiers=["tagv"], values=["\x00\x013"],
timestamp=9223372036854775807, lockid=-1, durable=true,
bufferable=true, attempt=0, region=null), which indicates this UID
must have been allocated concurrently by another TSD. So ID 307 was
leaked.
Following questions I have:
Since it is a warning, is it that the record is actually written and not skipped?
At the end it says, 'ID 307 was leaked', so is some other ID assigned to the record?
How to verify that the said record has been written in HBase's table named 'tsdb-uid'? (HBase shell commands, I tried a few but in vain).
This just means that a UID was allocated for nothing, but otherwise everything is fine. If you are worried about the state of your tsdb-uid table, you could run the tsdb uid fsck command, and it will probably report that some UIDs are allocated but unused.
If you see the message only occasionally, you can ignore it. If you see it a lot, then the only undesirable consequence is that you're burning through the UID space faster than you should be, so you may run out of UIDs sooner (there are 16777215 possible UIDs for each of: metric names, tag names, tag values).